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PREFACE 


This  paper  is  the  result  of  work  performed  by  the  Institute  for  Defense  Analyses 
(IDA)  under  contract  number  MDA  903  89  C  0003,  Task  Order  T-D6-553,  Amendment 
Number  1,  "Applications  of  Systems  Engineering  Techniques  to  the  Development  of  a 
Unified  Life  Cycle  Engineering  (ULCE)  Environment."  This  work  was  performed  for  the 
Air  Force  Human  Resources  Laboratory,  Logistics  and  Human  Factors  Division,  and  the 
Under  Secretary  of  Defense  for  Acquisition  (USD(A)).  The  document  satisfies  subtask  5, 
which  requires  identification  of  techniques  to  assist  a  design  team  in  a  hierarchical  design 
process  in  balancing  conflicting  design  goals  and  requirements  which  have  been  allocated 
to  the  team  either  by  a  customer  or  by  another  higher  level  design  team. 

This  paper  was  reviewed  by  Dr.  Jeffrey  Grotte  of  IDA,  Dr.  Joel  Tumarkin,  an  IDA 
consultant,  and  by  Dr.  Daniel  P.  Schrage  of  the  Georgia  Institute  of  Technology. 
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EXECUTIVE  SUMMARY 


Unified  Life  Cycle  Engineering  (ULCE)  is  an  Air  Force  Systems  Command  Project 
Forecast  II  research  and  development  program  whose  stated  goal  is 

to  develop,  demonstrate,  and  transfer  to  application  the  techniques  and 
technologies  needed  to  provide  advantageous  computerized  integration  of 
the  procedures  dealing  with  designing  for  producibility  and  supportability 
with  those  dealing  with  designing  for  performance,  cost,  and  scheduling 
[Ref.  1] 

In  1988,  the  Air  Force  requested  that  the  Institute  for  Defense  Analyses  (IDA) 
develop  an  architecture  for  a  computing  environment  within  which  ULCE  can  be 
implemented.  A  major  finding  of  the  resulting  study,  Architecture  and  Integration 
Requirements  for  an  ULCE  Design  Environment  [Ref.  2.],  was  that  the  concept  of  meta¬ 
design,  the  planning  of  the  design  decision  process,  must  play  a  central  role  in  an  ULCE 
architecture.  Meta-design  results  in  a  set  of  design  decision  tasks  and  a  procedure  for 
executing  these  tasks  that,  if  carried  out,  will  result  in  a  design  that  meets  the  user's 
requirements  in  a  near-optimal  manner,  as  judged  by  certain  explicit  criteria.  The  research 
reported  in  this  paper  further  develops  the  concept  of  meta-design,  demonstrates  the 
importance  of  meta-design  in  achieving  the  ULCE  program  goal,  and  presents  an  analytical 
aid  for  doing  meta-design  that  is  applicable  to  a  wide  variety  of  design  problems. 

A.  BACKGROUND 

In  recent  years,  the  issues  of  poor  weapon  system  quality,  high  cost,  and  long 
development  lead  time  have  received  considerable  attention  from  senior  management  within 
the  Department  of  Defense  (DoD).  The  design  process  has  long  been  recognized  as  a  major 
factor  contributing  to  these  problems. 

A  number  of  DoD  initiatives  have  advocated  improved  management  of  the  design 
process,  with  particular  emphasis  on  early  consideration  of  factors  such  as  producibility 
and  supportability.  Techniques,  such  as  Taguchi  Methods,  the  Boothroyd-Dewhurst 
Design  for  Assembly  Methodology,  and  Quality  Function  Deployment  (QFD)  have  been 
proposed  as  solutions.  A  well  disciplined  engineering  process  has  also  been  advanced  as 
the  key  to  obtaining  products  that  are  producible  and  supportable. 


While  techniques  and  procedures  are  valuable  aids  in  improving  design  practice, 
developing  a  design  that  is  balanced  in  terms  of  performance,  cost,  and  ility  characteristics 
can  pose  considerable  technical  challenges.  Situations  in  which  a  considerable  advance  in 
terms  of  performance  is  desired  and  in  which  new,  unproven  technologies  are  being 
incorporated  into  a  design,  present  significant  technical  difficulties  that  must  be  overcome 
before  a  life  cycle  engineering  approach  is  feasible.  New  weapon  system  design  projects 
usually  fall  into  this  category,  and  disciplined  management  practices  alone  are  not  sufficient 
to  address  these  technical  challenges. 

The  ULCE  initiative  was  undertaken  to  address  these  technical  issues.  Ultimately, 
a  combination  of  sound  design  management  practices  and  technology  advances  in  areas 
such  as  computer-aided  design  and  computer-aided  manufacturing  (CAD/CAM)  will  result 
in  the  DoD's  realizing  substantial  savings  in  ownership  costs  of  weapon  systems. 

B.  DESIGN  PROCESSES 

The  goal  of  ULCE  is  to  develop  a  design  environment  supportive  of  a  design 
process  in  which  producibility  and  supportabiiity  are  given  early  and  equal  consideration 
with  cost,  performance,  and  schedule.  An  ULCE  design  environment  cannot  be  developed 
successfully  without  considering  the  process  it  must  support.  The  structure  of  a  computing 
environment  to  support  ULCE  must  match  the  needs  of  the  designers  conducting  the 
activities  that  constitute  the  design  process. 

Design  begins  with  an  initial  specification  of  a  set  of  customer  requirements.  In 
response  to  these  requirements,  the  design  team  generates  a  number  of  design  concepts  that 
represent  potential  solutions  to  the  customer’s  requirements.  This  set  of  concepts  is  then 
typically  narrowed  to  a  few  concepts  that  offer  the  greatest  promise  for  meeting  the 
customer's  needs.  At  this  point,  the  concepts  are  analyzed  and  evaluated  to  determine  their 
feasibility;  the  values  of  key  design  parameters  that  specify  a  particular  version  or  instance 
of  the  concept  are  also  determined.  This  information  is  then  passed  on  to  the  next  phase  of 
design,  in  which  further  detailing  of  the  concept  takes  place. 

The  analysis  and  evaluation  portion  of  the  design  process  may  also  lead  to  a 
determination  that  the  concept  is  infeasible,  due  to  conflicts  in  requirements  or  specific 
features  of  the  concept.  The  design  team  must  develop  a  thorough  understanding  of  the 
design  problem  through  conduct  of  trade-off  analyses.  The  information  developed  through 
these  analyses  should  be  presented  to  the  customer  to  allow  him  to  make  an  informed 
decision  regarding  modifications  in  the  requirements. 


A  design  methodology  is  a  plan  for  conducting  the  analysis  and  evaluation  portion 
of  tne  design  process  for  a  particular  design  concept  and  set  of  requirements.  To  be 
successful,  a  design  methodology  must  lead— efficiently  and  with  a  minimum  number  of 
iterations— to  a  realization  of  the  design  concept  that  appropriately  balances  the  customer’s 
goals  and  requirements. 

When  the  nature  of  the  design  concept,  requirements,  and  associated  problems  fall 
within  the  domain  of  existing  engineering  knowledge,  an  existing  design  methodology  can 
be  used  to  conduct  the  analysis  and  evaluation  portion  of  the  design  process.  When  a  new 
concept  is  being  considered  (one  whose  principal  mode  of  operation  is  not  well 
understood,  uses  new  technologies,  or  uses  old  technologies  in  new  ways),  a  new  design 
methodology  must  be  developed. 

A  new  design  methodology  is  also  needed  when  the  nature  of  the  customer 
requirements  given  to  the  design  team  differs  from  those  requirements  that  have  been 
specified  to  the  design  community  in  the  past  for  similar  problems.  For  example,  if  the 
requirements  historically  levied  on  designers  have  been  such  as  to  allow  them  to  avoid  early 
consideration  of  producibility  in  the  design  process,  then  specification  of  new  requirements 
to  the  design  team  in  which  producibility  is  a  key  factor  will  require  a  new  design 
methodology.  Because  weapon  system  designers  have  not  commonly  considered 
producibility  or  supportability  early  in  the  design  process,  implementation  ULCH  will 
usually  require  development  of  new  design  methodologies. 

In  this  paper,  the  development  of  a  design  methodology  is  called  meta-design. 

C.  META-DESIGN  AND  THE  ULCE  ARCHITECTURE 

An  existing  design  process  geared  to  producing  designs  optimized  for  performance 
considerations  without  regard  to  cost,  schedule,  producibility,  or  supportability  is  not  an 
ULCE  design  process,  and  automating  such  a  process  will  not  lead  to  ULCE.  The 
sequence  of  design  decisions  of  the  existing  process  must  be  reordered  to  implement 
ULCE,  and  different  decisions  may  be  required.  Plans  for  integrating  CAD/CAM  tools, 
analysis  tools,  and  design  data  bases  should  be  directed  toward  executing  a  specific  ULCE 
design  methodology.  The  type  of  ULCE  design  methodology  used  will  depend  on  the 
type  of  design  problem  being  addressed. 

Implementing  a  different  computer  integration  scheme  for  each  design  methodology 
would  pose  a  considerable  burden  in  terms  of  software  development,  however.  An 


alternative  approach,  advocated  in  Reference  2,  entails  developing  a  flexible  design  system 
(FDS)  capable  of  supporting  the  activities  of  methodology  development  (meta-design)  and 
methodology  execution  (design)  for  multiple  design  problems.  Such  a  system  would  be 
analogous  to  a  flexible  manufacturing  system  in  that  it  could  be  rapidly  reconfigured  to 
support  production  of  many  different  designs. 

Simple  techniques  to  aid  in  meta-design  now  exist-Interpretive  Structural  Modeling 
(ISM)  and  the  Design  Structure  System  (DSS).  Both  of  these  techniques  are  based  on 
input  in  the  form  of  a  graphical  representation  of  the  design  concept  in  terms  of  design 
variables  and  relationships  among  these  variables.  These  techniques  allow  identification 
of  groups  of  design  attributes  that  may  be  determined  concurrently,  and  placing  these 
groups  into  a  sequence  specifying  the  order  in  which  they  are  to  be  addressed.  Such  a 
grouping  and  ordering  is  called  a  design  decision  plan. 

Unfortunately,  the  graphical  representations  used  as  input  to  ISM  and  DSS  do  not 
contain  sufficient  information  on  the  analytical  relationships  among  the  design  variables  to 
guarantee  that  decision  plans  derived  through  their  use  will  result  in  designs  that  are 
feasible  or  appropriately  balance  customer  goals.  Moreover,  these  simple  techniques  do 
not  aid  the  design  team  in  developing  the  information  needed  to  conduct  trade-off  analyses 
when  initial  requirements  conflict.  In  such  situations,  an  analytical  approach  to  meta¬ 
design  is  needed. 

D .  AN  ANALYTICAL  APPROACH  TO  META-DESIGN 

This  paper  presents  an  analytical  approach  to  meta-design  that  involves  two 
elements: 

•  A  framework  provided  by  optimization  theory  that  allows  the  convergence  of 
design  methodologies  to  be  assessed 

•  Specific  criteria  that  can  be  used  as  guidelines  in  synthesizing  design 
methodologies. 

To  develop  this  approach,  the  design  problem  is  formulated  in  terms  of  a  multi¬ 
objective  mathematical  optimization  problem.  Formulating  the  problem  in  terms  of 
optimization  is  important  because  it  provides  a  theoretical  framework  for  studying 
alternative  design  decision  processes.  In  particular,  the  analytical  notions  of  convergence 
and  rate  of  convergence  can  be  introduced  to  provide  quantitative  means  of  evaluating  the 
feasibility  and  efficiency  of  a  design  decision  process. 


Two  results  from  optimization  theory  form  the  foundation  for  the  methods 
presented  in  this  paper.  These  results  allow  proof  of  convergence  of  a  sequence  of  design 
decisions  to  a  balanced,  feasible  design.  The  criteria  that  guarantee  convergence  are 
outlined  in  Chapter  IV,  where  they  are  illustrated  by  application  to  a  simple  design 
problem.  The  underlying  mathematical  theory  is  contained  in  Appendix  B. 

Formulation  of  the  design  problem  in  terms  of  optimization  theory  does  not  imply 
that  the  problem  must  be  solved  by  numerical  optimization  methods.  The  approach 
contained  in  this  paper  uses  results  from  optimization  theory  to  aid  in  decomposing  a  large 
design  problem  formulated  in  this  way  into  a  set  of  smaller  problems.  How  these  smaller 
problems  are  solved  is  not  specified.  Methods  other  than  numerical  optimization,  including 
ad  hoc  approaches  based  on  engineering  judgment,  could  be  applied  to  yield  solutions  to 
these  problems.  In  fact,  with  large  problems,  solution  methods  other  than  numerical 
optimization  will  likely  be  essential. 

The  approach  presented  in  this  paper  leads  to  a  method  for  determining  the  entire 
family  of  Pareto-optimal  solutions  (solutions  in  which  the  value  of  a  particular  design  goal 
cannot  be  improved  except  at  the  expense  of  reducing  the  value  of  another  goal)  from  the 
solution  of  a  finite  number  of  single  objective  optimization  problems  and  partial  derivatives. 
This  information  is  important  in  the  requirements  negotiation  process,  and  this  method 
allows  such  information  to  be  developed  very  efficiently. 

E,  CONCLUSIONS 

The  success  of  techniques  such  as  Quality  Function  Deployment  strongly  depends 
on  the  existence  of  a  design  methodology  that  will  deliver  choices  for  design  attributes  that 
lead  to  balanced,  feasible  designs.  While  such  methodologies  exist  for  consumer  products 
(which  are  usually  based  on  derivatives  of  existing  systems),  such  methodologies  must  be 
invented  for  advanced  technology  systems.  The  lack  of  a  systematic  approach  for 
assessing  whether  a  given  design  methodology  will  deliver  a  product  balancing  a 
conflicting  set  of  requirements  has  been  a  contributing  factor  to  the  problems  encountered 
in  transitioning  these  systems  from  the  development  phase  to  production  and  operation. 
The  method  presented  in  this  paper  will  aid  in  solving  these  problems. 

Application  of  this  method  is  based  on  optimization  theory  but  is  independent  of  the 
use  of  specific  numerical  techniques  for  design  optimization.  Thus,  this  approach  can  be 
used  in  areas  of  design  where  numerical  optimization  techniques  have  been  difficult  to 
apply,  such  as  design  problems  where  rough  approximations  must  be  made  in  the 


engineering  theories  and  models  underlying  the  concept.  In  these  cases,  engineering 
judgment,  perhaps  based  on  comparison  of  predictions  made  by  several  approximate 
theories,  is  required  to  determine  values  for  design  variables. 

The  approach  developed  in  this  paper  also  promises  to  be  useful  in  engineering 
design  problems  having  attributes  that  are  subject  to  uncertainty  or  random  variations.  In 
this  context,  the  results  offer  the  means  to  systematically  extend  methods,  such  as  those  of 
Taguchi,  to  the  solution  of  complex  design  problems  in  the  development  of  advanced 
technology  systems. 

F.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

The  results  of  this  paper  suggest  that  additional  research  should  be  pursued  in 
several  areas. 

First,  the  methods  of  this  paper  should  be  demonstrated  and  evaluated  by  applying 
them  to  a  design  problem  comparable  in  scope  to  the  conceptual  development  of  an  aircraft 
system.  In  particular,  a  life  cycle  approach  to  this  problem  should  be  formulated  and 
executed  through  application  of  this  methodology. 

Research  into  the  application  of  the  ideas  contained  in  this  paper  to  product 
development  and  system  management  problems  characterized  by  uncertainty  or  random 
variations  in  the  design  attributes  should  be  also  be  pursued.  There  have  been  a  number  of 
successful  applications  of  Taguchi  methods  to  develop  designs  that  are  robust  under 
uncertainties  in  manufacturing  process  and  usage  environment.  The  methods  of  Taguchi, 
as  interpreted  by  Tse  [Ref.  24],  could  be  used  to  solve  the  optimization  subproblems 
identified  by  the  meta-design  procedure  of  this  paper,  allowing  the  Taguchi  approach  to  be 
applied  to  design  of  complex,  advanced  technology  systems. 

Another  promising  area  of  research  is  coupling  of  the  meta-design  approach  of  this 
paper  with  Quality  Function  Deployment  (a  matrix  technique  for  translating  customer  needs 
into  design  requirements).  This  would  lead  to  an  integrated  approach  to  the  total  design 
process— from  initial  systems  engineering  analyses  through  planning  and  execution  of 
specific  design  methodologies.  QFD  has  been  proven  useful  in  a  number  of  consumer 
product  development  activities,  and  has  also  been  used  successfully  as  a  high  level 
planning  tool.  Its  usefulness  in  complex,  advanced  technology  developments  is  limited  by 
its  non-analytic  approach.  Coupling  QFD  with  meta-design  techniques  such  as  those  of 
this  paper  could  remove  this  limitation. 


Finally,  the  convergence  theory  developed  in  this  paper  for  decomposition 
methods  of  optimization  should  receive  further  investigation.  Useful  results  concerning 
the  convergence  of  iterative  decomposition  methods  that  are  not  sequential  are  immediately 
accessible  using  the  techniques  developed  here. 


I.  INTRODUCTION 


Unified  Life  Cycle  Engineering  (ULCE)  is  an  Air  Force  Systems  Command  Project 
Forecast  II  research  and  development  program  whose  stated  goal  is 

to  develop,  demonstrate,  and  transfer  to  application  the  techniques  and 
technologies  needed  to  provide  advantageous  computerized  integration  of 
the  procedures  dealing  with  designing  for  producibility  and  supportability 
with  those  dealing  with  designing  for  performance,  cost,  and  scheduling 
[Ref.  1]. 

In  1988,  the  Air  Force  requested  that  the  Institute  for  Defense  Analyses  (IDA) 
develop  an  architecture  for  a  computing  environment  within  which  ULCE  can  be 
implemented.  A  major  finding  of  the  resulting  study,  Architecture  and  Integration 
Requirements  for  an  ULCE  Design  Environment  [Ref.  2.],  was  that  the  concept  of  meta¬ 
design,  the  planning  of  the  design  decision  process,  must  play  a  central  role  in  an  ULCE 
architecture.  Meta-design  results  in  a  set  of  design  decision  tasks  and  a  procedure  for 
executing  these  tasks  that,  if  carried  out,  will  result  in  a  design  that  meets  the  user’s 
requirements  in  a  near-optimal  manner,  as  judged  by  certain  explicit  criteria. 

The  research  reported  in  this  paper  further  develops  the  concept  of  meta-design, 
demonstrates  the  importance  of  meta-design  in  achieving  the  ULCE  program  goal,  and 
presents  an  analytical  aid  for  doing  meta-design  that  is  applicable  to  a  wide  variety  of 
design  problems.  This  research  extends  the  work  first  reported  in  Reference  2. 

A.  BACKGROUND 

The  issues  of  poor  quality,  high  cost,  and  long  development  lead  time  of  new 
weapon  systems  have  received  considerable  attention  from  senior  management  within  the 
Department  of  Defense  (DoD)  [Ref.  3],  It  has  long  been  recognized  that  these  shortcomings 
are  due  largely  to  the  process  by  which  weapon  systems  are  developed-and  in  particular 
the  way  they  are  designed.  For  example,  the  Defense  Science  Board  (DSB),  in  a  1982 
summer  study  [Ref.  4],  found  that  there  was  no  inherent  reason  why  high  performance 
weapon  systems  utilizing  advanced  technologies  should  exhibit  poor  operational 


availability  when  fielded.  If  such  systems  were  properly  designed,  with  early 
consideration  given  to  reliability,  maintainability,  and  other  field  support  factors,  they 
would  exhibit  a  high  level  of  availability. 

The  Boeing  Aerospace  Company,  in  a  study  examining  ballistic  missile  systems, 
found  that  while  only  1  percent  of  the  system  life  cycle  cost  (LCC)  was  expended  by  the 
end  of  the  concept  development  phase,  70  percent  of  that  system’s  LCC  was  implicitly 
determined  by  the  design  decisions  made  during  the  concept  development  phase  (Figure  I- 
1.)  By  the  end  of  full-scale  development  (FSD),  more  than  95  percent  of  the  system’s 
LCC  had  been  determined,  although  only  18  percent  of  this  cost  had  been  expended.  Thus 
it  is  in  the  design  phase  that  we  have  the  greatest  leverage  over  LCC-decisions  made  in  this 
phase  will  determine  most  of  the  subsequent  acquisition  and  ownership  costs  for  a  weapon 
system. 


SOURCE:  BOEING  COMPANY 

Figure  1-1.  Life  Cycle  Cost  Committed  versus  Expended  by  Life  Cycle  Phase 

(Ballistic  Missile  System) 

B .  RECENT  DEPARTMENT  OF  DEFENSE  INITIATIVES  ADDRESSING 
DESIGN 

Recognizing  the  importance  of  design,  during  the  past  few  years  DoD  has 
undertaken  several  initiatives  that  address,  among  other  things,  the  engineering  design 
portion  of  the  weapon  system  acquisition  process.  The  goal  of  these  initiatives  has  been  to 
improve  the  design  process  and,  as  a  result,  reap  significant  downstream  ownership  cost 


savings.  The  following  initiatives  are  representative  of  the  major  DoD  thrusts  addressing 
design. 

1 .  Transition  from  Development  to  Production 

In  a  summer  study  conducted  in  1983  [Ref.  5],  a  DSB  Task  Force  examined  why 
so  many  DoD  weapon  systems  programs  have  experienced  difficulties  in  making  the 
transition  from  the  engineering  development  phase  to  production.  Serious  producibility 
and  manufacturability  problems  have  plagued  many  DoD  weapons  programs,  resulting  in 
schedule  delays,  costly  redesign  activities,  and  systems  with  poor  reliability.  The  DSB 
Task  Force  found  that  these  problems  could  be  attributed  in  large  measure  to  lack  of 
appropriate  discipline  in  the  engineering  development  process,  especially  in  the  design 
process.  For  example,  the  failure  of  engineering  management  to  require  that  the  design 
team  consider  the  effect  of  their  decisions  on  producibility  was  cited  as  one  major  factor  in 
the  transition  problems. 

The  solution  advanced  by  the  DSB  Task  Force,  documented  in  Reference  5, 
involves  following  a  set  of  guidelines,  or  templates,  that  specify  at  which  points  in  the 
development  process  certain  activities  should  occur  to  minimize  the  risk  of  problems  in  the 
transition  to  production.  Reference  6  includes  similar  templates.  Such  templates  are  an 
extension  and  elaboration  of  the  standard  system  engineering  management  practices 
outlined  in  the  DoD  acquisition  regulations  and  taught  by  the  Defense  Systems  Management 
College  [Ref.  7].  The  first  of  the  templates  in  Reference  5  addresses  the  most  important 
and  problematical  aspect  of  weapon  systems  development— provision  for  adequate  up-front 
program  funding  to  allow  a  thorough  design  process  in  which  downstream  factors  are 
properly  considered.  Without  provision  of  such  funds,  successful  execution  of  the 
remaining  templates  becomes  difficult 

2.  R&M  2000 

The  goal  of  the  Air  Force  R&M  2000  Initiative  is  to  increase  the  combat  capability 
of  its  weapon  systems  by  improving  their  reliability  and  maintainability  (R&M) 
characteristics  [Ref.  8].  Test,  analyze,  and  fix  (TAAF)  procedures  were  emphasized  early 
in  the  R&M  2000  Initiative.  Recently,  the  program  has  emphasized  incorporating  R&  M 
considerations  into  the  design  process  as  early  as  possible. 

The  R&M  2000  initiative  advocates  a  design  approach  in  which  a  multifunctional 
team  uses  various  tools,  including  techniques  such  as  Quality  Function  Deployment  (QFD) 


[Ref.  9],  techniques  for  design  for  assembly  such  as  that  of  Boothroyd  and  Dewhurst 
[Ref.  10],  and  techniques  for  robust  design  (such  as  those  of  Taguchi  [Ref.  11])  to 
simultaneously  design  a  product  and  its  related  processes,  including  manufacture  and 
support.  Such  an  approach  is  called  simultaneous  engineering,  and  is  essentially 
equivalent  to  the  notion  of  concurrent  engineering,  to  be  discussed  later  in  this  chapter. 

3 .  Computer-Aided  Acquisition  and  Logistics  Support 

The  Joint  Industry/DoD  Task  Force  on  Computer-Aided  Logistics  Support  (CALS) 
[Ref.  12]  advocated  integration  of  R&M  considerations  early  in  the  design  process  through 
use  of  computer-aided  design/computer-aided  engineering  (CAD/CAE)  technology.  The 
Air  Force  R&D  program  on  Reliability  and  Maintainability  in  Computer-Aided  Design 
(RAMCAD)  is  presently  using  this  approach. 

In  recent  years,  the  scope  of  the  CALS  program  has  broadened  to  include  the  entire 
acquisition  function  (hence  the  change  in  the  program’s  name  to  Computer-Aided 
Acquisition  and  Logistics  Support).  The  program  has  expanded  its  emphasis  on  early 
consideration  of  R&M  to  include  early  consideration  by  designers  of  all  of  those  ility 
characteristics,  including  producibility,  which  in  their  totality  define  the  quality  of  a  weapon 
system.  Concurrent  Engineering  (CE)  is  the  product  development  process  advocated  by 
the  CALS  program  to  accomplish  this.  Concurrent  engineering  addresses  all  of  the 
problems  that  must  be  overcome  to  conduct  an  effective  product  development  process. 


4 .  Concurrent  Engineering 

Concurrent  Engineering  is  defined  as 

a  systematic  approach  to  the  integrated,  concurrent  design  of  products  and 
their  related  processes,  including  manufacture  and  support.  This  approach 
is  intended  to  cause  the  developers,  from  the  outset,  to  consider  all  elements 
of  the  product  life  cycle  from  conception  through  disposal,  including 
quality,  cost,  schedule,  and  user  requirements  [Ref.  13]. 

CE  thus  requires  the  development,  in  parallel  with  the  product  design,  of  all  related 
processes  including  the  product’s  maintenance  concept  and  logistics  support  structure. 
Clearly,  CE  implies  the  use  of  a  multifunctional  team  approach  to  system  development. 
This  approach  makes  provision  for  the  ilities  specialists  to  appropriately  influence  the 
design  by  serving  as  members  of  the  design  team.  The  team  has  various  tools  and 
techniques  such  as  QFD  at  its  disposal  to  aid  in  structuring  and  tracking  design  activities 
and  decisions. 

Concurrent  engineering  emphasizes  not  only  quality  improvement  but  also 
reduction  of  acquisition  cost  and  development  lead  time.  Concurrent  engineering  lowers 
acquisition  cost  because  errors  in  the  design  are  detected  and  corrected  early  in  the  design 
process.  (Errors  discovered  further  into  the  development  process  cost  more  to  correct  than 
those  discovered  early.)  Changes  that  can  be  made  without  modifying  hardware  are  nearly 
always  less  costly  than  those  requiring  hardware  modifications,  and  the  amount  of 
hardware  that  must  be  modified  as  a  result  of  a  design  change  increases  as  the  development 
process  progresses.  Design  changes  made  after  the  product  is  in  production  may 
necessitate  retooling  of  the  factory,  an  extremely  expensive  process. 

Early  detection  and  correction  of  errors  also  leads  to  reduced  development  lead  time 
because  errors  discovered  early  in  the  development  process  can  be  addressed  by  fewer 
people  than  errors  discovered  later  in  the  process.  As  the  development  process  progresses 
and  the  level  of  detail  of  the  design  and  its  related  processes  increases,  the  number  of 
people  and  organizations  involved  in  the  design  effort  also  increases.  A  design  change  late 
in  the  process  must  be  coordinated  with  all  of  the  individuals  and  organizations  involved, 
leading  to  serious  management  and  communications  problems~and  delays  in  finalizing  the 
solution  to  the  design  error. 

Requirements  and  goals  are  prioritized  in  the  design  process  by  the  order  or 
sequence  in  which  they  are  addressed  by  design  decisions.  The  conventional  approach  to 
design  has  been:  first,  find  a  way  to  make  the  system  work,  then,  figure  out  how  to  build 


the  system,  after  that,  decide  out  how  to  support  the  system,  and  finally  address  the 
problem  of  disposal.  To  accomplish  concurrent  engineering,  we  must  consider  at  least 
three  of  these  phases  (design  for  performance,  producibility,  and  supportability)  in  a 
tightly-coupled  parallel  decision-making  process.  The  reason  for  doing  this  is  to  achieve  a 
better  balance  between  performance,  producibility,  supportability,  cost,  and  schedule. 
Thus,  the  idea  that  design  goals  are  balanced  through  the  sequence  in  which  requirements 
are  addressed  is  central  to  the  goals  of  concurrent  engineering. 

5  .  Total  Quality  Management 

The  goal  of  the  DoD  Total  Quality  Management  (TQM)  initiative  [Ref.  14]  is  to 
promote  and  implement  continuous  process  improvement  throughout  the  DoD 
infrastructure.  This  initiative  is  based  on  the  quality  improvement  and  management 
methods  of  Deming  [Ref.  15]  and  Juran  [Ref.  16],  among  others.  These  methods  stress 
the  importance  of  strong  leadership  in  an  organization,  use  of  tools  and  techniques  for 
understanding  processes,  use  of  statistical  process  control  (SPC)  to  track  and  control 
variability  in  processes,  and  instilling  pride  of  workmanship  and  the  desire  for  continual 
improvement  in  each  member  of  the  organization.  TQM  requires  teamwork  across 
functions,  and  development  and  nurturing  of  a  team  approach  to  improvement  provides  the 
foundation  for  implementing  TQM. 

CE  can  be  viewed  as  the  application  of  TQM  principles  to  product  development 
[Ref.  3].  TQM  is  a  broader  concept  than  CE  that  is  also  applicable  to  other  functional 
areas  of  an  organization,  such  as  customer  service  and  distribution.  Cultural  change  must 
occur  if  a  TQM  approach  is  to  take  hold.  Facilitating  such  change  is  one  of  the  greatest 
management  challenges  facing  DoD  and  US  industry  during  the  coming  years. 

C.  UNIFIED  LIFE  CYCLE  ENGINEERING 

The  initiatives  cited  in  the  preceding  paragraphs  all  have  goals,  which  if  achieved, 
will  be  beneficial  to  DoD.  However,  little  progress  has  been  made  in  achieving  these  goals 
in  DoD  weapon  systems  acquisition.  Serious  obstacles  must  be  overcome  to  achieve  these 
goals,  such  as  cultural  barriers  and  developmental  funding  profiles,  which  are  not 
conducive  to  improved  design  processes,  and  DoD  acquisition  regulations  that  sometimes 
impede  rather  than  encourage  better  design  practice.  Beyond  these  problems,  another 
overriding  issue  must  be  addressed  if  improved  design  processes  are  to  be  achieved- 


determining  a  specific  and  detailed  procedure  for  implementing  the  recommendations  of 
these  initiatives  in  a  specific  product  development  program. 

All  of  the  initiatives  have  adequately  stated  the  problem  faced  by  developers 
attempting  to  incorporate  life  cycle  considerations  early  in  the  design  process.  Statements 
of  the  problem  of  life  cycle  engineering  have  been  available  for  years  (see,  for  example. 
References  17  and  18.)  Stating  the  problem  is  one  thing-solving  it  is  another  matter. 
Significant  technical  problems  must  be  addressed  to  arrive  at  a  solution. 

1 .  Dealing  with  Complexity— The  Need  for  ULCE 

In  most  cases  of  DoD  weapon  system  acquisition,  the  technical  barriers  to 
implementation  of  life  cycle  engineering  can  be  attributed  to  the  complexity  of  the  system 
being  developed,  the  demands  being  placed  on  the  system  to  significantly  advance  the 
current  state  of  the  art  in  terms  of  performance,  and  the  increase  in  the  complexity  of  the 
design  problem  if  life  cycle  considerations  are  introduced.  A  weapon  system  developer 
attempting  to  take  a  life  cycle  engineering  approach  faces  an  enormous  task.  (See  Reference 
19.)  The  team  approach  to  product  design  has  limitations  when  the  size  of  the  project 
becomes  very  large.  (See  Reference  20.)  Management  methods  alone  are  unlikely  to  be 
sufficient  to  make  life  cycle  engineering  feasible  for  complex  products. 

The  Air  Force  ULCE  R&D  program  has  advocated  using  the  power  of  the  computer 
as  a  mechanism  for  getting  a  handle  on  the  complexity  of  the  life  cycle  engineering 
problem.  Computer-aided  design  and  engineering  (CAD/CAE)  systems  have  greatly 
increased  engineering  productivity,  especially  in  areas  such  as  design  of  very  large-scale 
integrated  (VLSI)  circuits  and  complex  avionics  systems.  In  addition,  a  number  of 
standalone  analysis  programs  are  available  for  assessing  designs  for  various  aspects  of 
supportability  and  estimating  life  cycle  costs.  The  hypothesis  underlying  ULCE  is  that  by 
integrating  such  programs  with  the  designer's  CAD/CAE  systems,  the  power  needed  to 
handle  the  increased  complexity  of  life  cycle  engineering  will  be  made  available  to  the 
design  team.  The  proponents  of  ULCE  believe  that  through  computer  power,  life  cycle 
engineering  will  become  feasible,  even  for  complex  weapon  systems. 

2  .  ULCE  Program  Challenges 

ULCE  seeks  to  develop  a  computer-based  environment  to  support  the  activities  in  a 
design  process.  As  a  result,  development  of  an  ULCE  environment  cannot  be  undertaken 
independent  of  this  process.  But,  how  does  one  specify  a  design  process  that  implements 


the  goals  of  ULCE?  Is  there  an  architecture  for  a  life  cycle  engineering  design  process  that 
can  be  developed  and  used  as  a  basis  for  developing  an  ULCE  design  environment? 

IDA  was  tasked  by  the  Air  Force  to  develop  an  architecture  for  an  ULCE  design 
process  and  a  computing  environment  to  support  such  a  process,  for  a  specific  design 
problem  [Ref.  2].  IDA  undertook  this  task  with  a  major  defense  contractor,  Lockheed 
Aeronautical  Systems  Company.  The  design  of  a  high  sink  rate  landing  gear  for  the  C-130 
was  selected  as  the  design  problem  to  be  used  as  a  baseline  for  developing  the  architecture. 

During  the  course  of  the  study  the  study  team  documented  the  current  design 
process  for  landing  gear  at  Lockheed  and  arrived  at  the  following  conclusions: 

•  No  unique  ULCE  design  process  exists,  even  for  a  specific  class  of  design 
problems  such  as  landing  gear  design. 

•  An  ULCE  design  process  will  depend  on  the  specific  requirements  being 
placed  on  the  design  (in  particular,  the  requirements  relating  to  producibility, 
supportability  and  performance,  cost  and  schedule). 

•  An  ULCE  design  process  will  also  depend  on  the  specific  product  being 
designed  as  well  as  the  specific  company  in  which  the  design  activities  are 
being  conducted. 

Thus,  the  problem  of  developing  a  single  generic  ULCE  architecture,  for  a  process 
or  an  environment,  is  indeterminate-no  such  architecture  can  be  specified  a  priori.  At  best 
one  can  define  a  higher  level  architecture  in  which  a  key  element  is  development  of  the 
specific  design  process  to  suit  the  problem  at  hand.  If  a  single  design  environment  is  to  be 
developed  to  support  ULCE,  it  must  be  sufficiently  flexible  to  support  multiple  design 
processes.  The  activity  of  developing  a  specific  design  process,  given  the  design 
requirements  and  a  design  concept,  is  called  meta-design.  The  remainder  of  this  report 
details  this  concept. 

D .  ORGANIZATION  OF  THE  REPORT 

Chapter  II  discusses  the  need  for  meta-design  by  describing  the  nature  of 
engineering  design  and  the  engineering  design  process,  introduces  the  concept  of  meta¬ 
design  as  a  planning  step  within  the  design  process,  and  demonstrates  how  meta-design 
relates  to  ULCE  and  to  the  ULCE  architecture  presented  in  Reference  2. 

Chapter  III  further  refines  the  concept  of  meta-design,  addressing  its  input 
requirements  and  outputs.  This  chapter  also  compares  various  approaches  for  doing  meta¬ 
design  and  identifies  specific  requirements  for  a  meta-design  approach  for  design 
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problems,  such  as  aircraft  design,  that  are  inherently  complex  and  exhibit  tight  coupling 
among  different  design  disciplines.  These  requirements  led  to  the  development  of  the 
analytical  techniques  to  aid  in  meta-design  that  are  presented  in  this  paper. 

Chapter  IV  presents  an  analytical  aid  for  meta-design  that  can  be  applied  to  a  wide 
variety  of  design  problems,  including  aircraft  conceptual  design.  The  theory  underlying 
this  approach  is  illustrated  by  applying  it  to  a  simple  design  problem. 

Chapter  V  presents  the  conclusions  of  the  study  and  outlines  additional  research 
needed  to  implement  the  algorithm  in  a  computer  based  tool  that  can  be  used  in  real-world 
design  projects. 

Appendix  A  outlines  specific  requirements  for  a  computing  environment  to  support 
meta-design.  It  provides  elaboration  of  the  discussion  in  Reference  2  regarding  the  notions 
of  object-centered  environments  and  constraint  propagation— two  paradigms  of  advanced 
computing  technology  that  are  needed  for  an  efficient  computer  support  of  meta-design  and 
for  effective  integration  of  meta-design  with  the  other  activities  in  an  ULCE  design  process. 

Appendix  B  contains  the  mathematical  details  underlying  the  meta-design  algorithm 
presented  in  Chapter  IV,  including  proofs  of  those  theorems  establishing  its  convergence. 

Appendices  C  and  D  contain  more  detailed  examples  of  the  application  of  the 
algorithm  to  problems  in  aircraft  design. 
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II.  ENGINEERING  DESIGN  AND  META-DESIGN 


An  ULCE  design  environment  must  support  an  ULCE  design  process.  An 
engineering  design  process  is  more  than  the  creation  of  a  set  of  engineering  drawings  (or 
computer  files).  A  design  process  is  a  human  activity  characterized  by  creativity,  conflict, 
negotiation,  and  compromise.  The  ULCE  program,  if  it  is  to  be  successful,  must  develop 
an  environment  that  supports  all  of  these  activities. 

In  this  section,  a  general  model  of  an  engineering  design  process  is  presented  to 
highlight  issues  that  must  be  addressed  in  developing  an  ULCE  environment  and  to  provide 
a  foundation  for  the  work  described  in  the  remainder  of  the  paper.  This  section  places 
meta-design,  the  development  of  a  design  decision  making  process,  in  the  context  of  the 
overall  design  process. 

A.  ENGINEERING  DESIGN  PROCESSES 

For  the  purposes  of  this  report,  an  engineering  design  process  may  be  defined  as  a 
sequence  of  interrelated  activities  that  begins  with  provision  of  an  initial  set  of  customer 
requirements  and  ends  with  one  of  the  following: 

•  A  complete  description  of  a  product  satisfying  these  requirements 

•  A  complete  description  of  a  product  satisfying  a  set  of  suitably 
modified  requirements  (through  mutual  agreement  between  design 
team  and  customer) 

•  A  determination  that  no  product  satisfying  the  stated  requirements 
is  feasible  and  that  modification  of  these  requirements  is  not 
acceptable  to  the  customer. 

Figure  II- 1  illustrates  one  view  of  the  engineering  design  process  as  performed  at 
one  level  of  design  detail. 


1 .  Identifying  and  Selecting  Design  Concepts 

The  first  task  of  the  design  team  is  to  identify  a  large  number  of  design  concepts 
that  could  possibly  satisfy  the  customer’s  requirements.  The  concepts  are  identified 
through  brainstorming  sessions  or  some  other  group  process  in  which  alternative  concepts 
can  be  advanced  by  any  member  of  the  team.  Because  creativity  is  the  key  factor  in 
developing  good  design  concepts,  the  nature  of  computer  support  that  is  appropriate  at  this 
stage  of  the  design  process  will  likely  be  different  than  that  provided  to  support  later  stages 
of  design,  which  are  more  analytically  oriented. 

If  the  design  team  seeks  to  take  a  life  cycle  engineering  approach,  then  team 
members  who  are  specialists  in  the  various  Hides  must  contribute  ideas.  These  ideas  may 
later  be  determined  infeasible,  but  all  possible  alternatives  should  be  expressed  and 
discussed  at  this  stage  of  design.  Selectively  adopting  features  from  one  or  more  of  these 
infeasible  concepts  may  lead  to  a  final  concept  with  better  downstream  design 
characteristics  (such  as  producibility  or  supportability). 

Through  the  concept  selection  stage,  feasibility  of  the  concepts  is  not  known— the 
concepts  are  considered  possible  solutions  awaiting  further  analysis  and  refinement.  The 
next  step,  analysis  and  evaluation,  has  as  its  goal  establishing  feasibility  of  a  concept. 
Because  this  step  is  usually  time  consuming  and  expensive,  the  design  team  tends  to 
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restrict  evaluations  to  the  most  promising  design  concepts.  In  this  discussion,  we  will 
assume  that  one  preferred  concept  is  chosen  for  analysis  and  evaluation.  The  team  could 
also  form  several  subteams  to  analyze  and  evaluate  several  concepts  in  parallel.  In  the  case 
of  subteams,  the  top-level  decision  process  would  have  to  be  altered  to  add  a  stage  for 
selecting  from  among  the  alternative  concepts  after  each  had  been  evaluated. 

2 .  Analysis  and  Evaluation 

Only  through  the  analysis  and  evaluation  process  can  the  design  team  determine 
whether  the  selected  concept  represents  a  viable  solution  to  the  customer’s  problem.  The 
nature  of  the  evaluation  and  analysis  to  be  conducted  will  depend  on  the  particular  design 
problem.  In  some  cases,  detailed  mathematical  models  will  be  created  and  exercised  to 
predict  the  potential  performance  of  the  concept.  Engineering  judgment  may  play  a  key 
role,  and  prototypes  may  be  built.  The  goal  of  all  these  activities  is  to  determine— with  a 
high  degree  of  confidence—that  the  given  concept  can  be  physically  realized  to  meet  the 
customer's  requirements. 

The  process  by  which  the  feasibility  of  a  concept  is  determined  is  known  as  sizing. 
This  process  may  involve  exercising  fairly  elaborate  computer  codes  that  involve 
mathematical  optimization,  as  is  done  in  aircraft  design.  This  process  should  establish  both 
feasibility  and  a  preferred  configuration  for  the  concept  (specification  of  actual  values  for 
various  parameters  defining  the  concept,  such  as  wingspan  and  weight).  If  the  team 
determines  that  there  is  a  good  probability  that  the  concept  can  be  further  refined  to  a 
complete  design  meeting  the  customer's  needs,  the  process  proceeds  to  the  next  level  of 
design  detail. 

The  sizing  process  can  also  show  that  the  concept  is  not  feasible--that  no  values  can 
be  assigned  to  the  parameters  defining  the  concept  that  will  result  in  a  design  meeting  the 
customer's  requirements.  It  is  not  sufficient,  however,  for  the  design  team  to  determine 
that  a  concept  is  infeasible— the  team  must  also  understand  why  it  is  infeasible  and  what 
changes  can  be  made  in  the  concept  to  make  it  feasible.  This  step  involves  identifying 
which  customer  requirements  lead  to  infeasibility.  Trade  studies  may  be  conducted  to 
determine  how  relaxing  certain  requirements  affects  the  ability  of  the  concept  to  meet  other 
requirements. 

The  design  team  should  also  seek  to  understand  which  features  of  the  concept 
contribute  to  its  failure.  They  should  determine  whether  one  or  more  of  these  features  can 
be  modified  to  obtain  a  concept  that  is  feasible.  If  so,  another  iteration  of  analysis  and 
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evaluation  with  the  modified  concept  should  be  undertaken.  If  this  iteration  establishes 
feasibility  of  the  modified  concept,  the  team  proceeds  to  the  next  level  of  design  detail  (or 
the  concept  is  handed  off  to  another  team  for  further  refinement.) 

3 .  Conflict  and  Negotiation 

If  a  concept  is  deemed  infeasible  and  no  simple  modification  of  the  chosen  concept 
can  be  shown  to  be  feasible,  the  design  team  must  decide  whether  to  select  another  concept 
and  repeat  the  evaluation  process  or  to  present  the  customer  with  suggested  modifications 
of  the  requirements  that  will  make  the  current  concept  feasible.  Selecting  a  new  concept 
and  repeating  the  sizing  process  entails  additional  cost  and  design  time-the  decision  to 
repeat  the  process  will  therefore  depend  on  the  project  budget  and  schedule  and  the 
likelihood  that  an  alternative  concept  will  prove  feasible. 

If  available  time  and  funds  do  not  permit  evaluation  and  analysis  of  another 
concept,  the  design  team  should  be  prepared  to  present  the  customer  with  potential 
modifications  to  specific  requirements  that  will  allow  the  current  concept  to  be  refined  into  a 
feasible  design.  At  this  point,  the  information  developed  in  trade-off  analyses  is  crucial  in 
aiding  the  design  team  in  making  recommendations  and  assisting  the  customer  in  making 
informed  decisions.  Should  the  customer  accept  an  appropriate  modification  in 
requirements,  the  concept  can  then  be  sized  and  passed  to  the  next  stage  of  the  design 
process  for  more  detailed  refinement.  If  the  customer  is  not  agreeable  to  changing  the 
requirements  or  providing  additional  funding  for  exploration  of  additional  concepts,  the 
only  alternative  course  of  action  is  project  cancellation. 

Conflicting  requirements  quite  frequently  lead  to  an  initial  concept  being  infeasible- 
especially  in  weapon  system  developments  in  which  a  significant  advance  in  the  state  of  the 
art  in  terms  of  performance  is  desired  (see  Reference  21  for  further  discussion).  If  a 
design  environment  is  to  be  used  in  support  of  weapon  system  developments,  provision 
should  be  made  for  the  environment  to  support  the  management  and  resolution  of  such 
conflicts. 

Moreover,  in  contrast  to  mathematical  optimization,  in  which  an  algorithmic 
solution  is  sought  to  a  problem  that  is  unambiguously  stated  and  well  understood,  design 
problems  are  often  stated  ambiguously  and  are  not  well  understood  by  the  design  team  or 
the  customer-at  least  at  the  outset  of  the  design  project.  A  critical  element  of  design  is  the 
learning  process  that  takes  place  among  design  team  members  (and  the  customer)  as 
conflicting  requirements  are  identified  and  the  nature  of  the  problem  is  clarified  [Refs. 


22,23].  Development  of  a  deeper  level  of  understanding  of  the  design  problem  by  the 
design  team  is  as  important  a  product  of  the  design  process  as  the  final  drawings  for  the 
design  itself. 

The  distinction  between  design  and  mathematical  optimization  is  relevant  to  the 
ULCE  program,  because  one  of  the  goals  of  ULCE  is  to  develop  a  design  environment  that 
allows  designs  to  be  optimized  for  producibility  and  supportability  as  well  as  performance, 
cost,  and  schedule  [Ref.  1].  Mathematical  optimization  is  certainly  one  tool  that  can  be 
applied  to  this  problem  in  some  cases.  An  ULCE  architecture  should  be  structured  to 
support  the  total  design  process  and  not  just  a  particular  tool  that  might  be  used  in  that 
process. 

4.  Refinement  of  the  Concept 

The  representation  of  the  design  process  in  Figure  II- 1  captures  the  activities  at  one 
level  of  refinement  of  the  design.  As  the  design  progresses  from  conceptual  through 
preliminary  design  and  on  to  the  detailed  design  phase,  the  results  of  each  phase  flow  down 
to  the  next  design  phase.  This  arrangement  of  design  activities  is  illustrated  in  Figure  II-2. 


Figure  11-2.  Hierarchy  of  Design  Processes 
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This  flow-down  process  has  associated  risks-there  are  no  guarantees  that  design 
teams  at  lower  levels  can  meet  the  requirements  allocated  by  the  preceding  level  of  design, 
and  the  risks  are  significantly  greater  when  a  new  technology  must  be  developed  for  a 
lower  level  design  team  to  meet  requirements.  Should  the  requirements  at  a  lower  level  of 
design  not  prove  achievable,  then  a  negotiation  process  must  be  undertaken  between  the 
lower  level  team  and  the  higher  level  team  assigning  the  requirements.  The  situation  is 
further  complicated  by  the  fact  that  a  change  in  requirements  that  have  been  assigned  to  one 
team  may  necessitate  changes  to  requirements  previously  assigned  to  other  teams,  which 
results  in  multiple  redesign  activities  and  leads  to  considerable  problems  in  coordination  of 
efforts.  This  situation  often  results  in  cost  overruns  and  schedule  slippage.  An  analytical 
framework  for  managing  these  types  of  risk  is  given  in  Reference  24. 


B  .  DESIGN  METHODOLOGIES 

A  specific  procedure  for  establishing  the  feasibility  of  a  concept  and  developing 
understanding  within  the  design  team  of  how  and  why  the  concept  works  (or  doesn't 
work)  is  called  a  design  methodology.  A  design  methodology  is  specific  to  a  particular 
concept  and  set  of  requirements.  The  portion  of  the  overall  design  process  that  constitutes 
execution  of  a  design  methodology  is  highlighted  in  Figure  II-3. 


Customer  Design  Team  (interacting  with  the  customer) 


Execution  of  a  Design  Methodology 


Continue  to 
next  level  oi  [ 
refinement 
I  of  the  design  I 


Note:  Boxed  portion  represents  execution  of  a  design  methodology 


Figure  11-3.  Top-Level  Design  Process 


A  design  methodology  is  a  procedure  for 

•  Determining  what  design  decisions  should  be  made  and  in  what  sequence 

•  Determining  what  analyses  should  be  done  to  support  these  decisions 

•  Identifying  specific  trade  studies  that  should  be  conducted. 

Execution  of  a  design  methodology  provides  answers  to  the  following  questions: 

•  Can  the  general  design  concept  be  realized  in  such  a  way  that  it  will  meet  the 
customer's  requirements?  (establishing  feasibility) 

•  If  the  concept  cannot  be  realized,  what  are  the  limiting  factors  or  constraints 
that  prevent  a  feasible  realization  of  the  concept?  (generating  understanding) 

A  design  methodology  is  an  essential  component  supporting  the  design  process— it 
provides  the  means  for  verifying  that  a  concept  is  viable  and  for  making  design  decisions 
that  will  be  forwarded  as  inputs  to  the  next  level  of  design.  Execution  of  a  design 
methodology  also  costs  money  and  takes  time— making  efficiency  an  important  criteria  in 
the  choice  of  a  design  methodology. 

A  good  design  methodology  should  also  have  the  following  characteristics: 

•  It  should  be  workable— if  the  design  concept  is  viable,  the  design  methodology 
should  lead  to  a  feasible  realization  of  that  concept. 

•  It  should  be  transparent-the  methodology  should  be  readily  understood  by  the 
design  team. 

•  It  should  decrease  risk-by  increasing  the  design  team's  confidence  that  the 
resulting  design  will  meet  the  customer's  requirements. 

Design  methodologies  have  been  developed  for  many  types  of  design  problems. 
Some  methodologies  are  documented  in  engineering  textbooks  and  other  reference  works, 
others  are  retained  within  corporations  as  proprietary  information  used  in  development  of 
new  products,  and  others  are  retained  within  the  minds  of  highly  experienced  engineers. 

These  methodologies  have  been  developed  over  the  course  of  the  years  through 
various  means: 

•  Through  experience  and  learning  derived  from  many  failures  and  some  notable 
successes  -  aircraft  design  is  a  good  example  of  this  approach. 

•  Through  research  activities  (of  companies  and  universities).  Silicon 
compilation-an  approach  to  VLSI  chip  design  developed  by  Carver  Mead  and 
Lynn  Conway,  is  an  example  of  a  design  methodology  developed  through 
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research.  These  investigations  are  ultimately  codified  into  recommended 
design  practices. 

•  By  analytical  methods.  Tools  being  developed  at  institutions  such  as  MIT  ® 

[Ref.  25]  and  Lockheed  Aeronautical  Systems  Company  [Ref.  26]  aid 

designers  in  structuring  a  design  decision  process.  Such  tools  are  of  particular 
value  in  helping  designers  deal  with  problems  in  which  a  workable 
methodology  is  unknown.  ^ 

•  By  some  combination  of  these  approaches  (most  existing  methodologies  fall 
into  this  category). 

The  design  methodology  chosen  by  the  team  will  depend  on  the  particular  concept 
under  consideration  and  on  the  nature  of  the  requirements  that  must  be  satisfied  by  the  • 

design.  An  industry  example  can  be  used  to  illustrate  this.  Figure  II-4  represents  the 
design  methodology  that  was  in  use  at  Lockheed  Aeronautical  Systems  Company  (Georgia) 
for  the  design  of  the  high  sink  rate  landing  gear  for  the  C-130  [Ref.  2], 


Figure  11-4.  Landing  Gear  Design  Process  at  Lockheed 
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The  sequence  of  activities  and  decisions  in  this  methodology  is  determined  largely  by 
schedule  considerations— the  need  to  obtain  a  feasible  design  in  the  least  amount  of  time 
(and  at  minimal  design  cost)  and  achieve  timely  delivery  of  design  data  packages  to  the 
customer.  The  biggest  cost  driver  in  this  design  methodology  is  the  generation  of  detailed 
design  data  (drawings).  This  activity  occurs  late  in  the  process,  and  as  a  result, 
consideration  of  factors  such  as  producibility  and  supportability,  which  require  detailed 
design  information  for  assessment,  are  also  pushed  to  the  end  of  the  process.  This 
schedule  permits  very  little  flexibility  for  incorporation  of  changes  in  the  design  should 
problems  be  discovered  relating  to  these  factors. 

If  the  customer  specifies— as  an  initial  requirement— that  producibility  and 
supportability  were  to  be  considered  equally  with  schedule  and  cost,  the  methodology 
illustrated  in  Figure  II-4  would  not  be  appropriate.  The  sequence  of  design  decisions 
would  have  to  be  re-examined  and  changed  to  accommodate  these  new  requirements.  The 
issue  of  determining  the  new  sequence  of  decisions  and  design  activities  constitutes  part  of 
the  activity  of  meta-design,  which  is  discussed  in  the  following  section  and  in  Chapters  HI 
and  IV. 

C.  META-DESIGN-DESIGNING  A  DESIGN  METHODOLOGY 

When  the  design  team  has  selected  a  promising  concept  that  seems  likely  to  meet  the 
customer's  requirements,  the  team  must  then  plan  the  analysis  and  evaluation  of  the 
concept.  They  must  select  or  develop  a  design  methodology  that  they  will  execute  to 
develop  understanding  of  the  concept  and  the  requirements,  prove  feasibility  of  the 
concept,  or  identify  potential  changes  in  the  concept  and  the  requirements  to  recommend  to 
the  customer.  This  planning  stage  is  called  meta-design.  During  this  stage,  the  design 
team  is  designing  a  portion  of  the  design  process— thus  they  are  engaged  in  a  design  activity 
at  a  higher  level  of  abstraction  than  the  design  of  the  product. 

Other  researchers  have  also  defined  a  meta-design  concept.  For  example,  Mistree 
[Ref.  23]  defines  meta-design  in  two  parts: 

•  Partitioning  —  defining  and  partitioning  a  problem  using  a  discipline 
independent  modeling  technique 

•  Planning  —  organizing  the  expertise  of  individuals  and  the  information  (and 
knowledge)  embodied  in  databases,  and  computers 

This  definition  applies  throughout  the  design  process,  from  concept  development 
through  detailed  design.  However,  the  actual  activities  which  make  up  the  partitioning  and 


planning  components  change  as  one  progresses  through  the  design  process.  Our  concept 
of  meta-design  corresponds  roughly  to  the  partitioning  portion  of  Mistree's  definition,  and 
we  do  use  a  discipline  independent  modeling  technique  (derived  from  results  in 
mathematical  optimization  theory)  in  the  analytical  aid  to  meta-design  developed  in  Chapter 
IV.  Planning  as  defined  by  Mistree  follows  logically  from  the  results  of  partitioning,  but 
represents  a  step  not  explicitly  considered  in  this  report.  Moreover,  in  this  report,  we 
restrict  our  consideration  to  meta-design  as  applied  to  that  portion  of  the  design  process  that 
involves  the  analysis,  evaluation,  and  trade-off  studies  for  a  specific  concept.. 

Meta-design  is  usually  done  by  experienced  engineers— system  engineers  and 
program  managers— for  the  top-level  design  activities  of  a  large  project.  However,  at 
lower  levels  of  the  hierarchy  in  large  design  projects,  meta-design  is  done  by  the  design 
team.  At  the  lowest  level,  meta-design  is  done  by  a  single  designer  (sometimes  implicitly 
or  subconsciously)  in  planning  his  own  work.  Meta-design  is  closely  related  to 
engineering  management— the  choice  of  a  design  methodology  will  clearly  affect 
development  cost  and  schedule.  Meta-design  is  the  intersection  of  the  technical  and 
management  domains  of  a  new  product  development  project. 

1 .  Types  of  Meta-Design 

Like  ordinary  product  design,  meta-design  can  be  categorized  into  three  classes  (see 
Mistree,  [Ref.  23]): 

•  Routine  meta-design :  The  design  concept  and  requirements  fall  within  the 
domain  of  established  engineering  knowledge  and  experience.  A  documented 
design  methodology  is  available  that,  if  executed,  will  lead  the  team  to  a 
feasible  design  or  demonstrate  that  no  such  design  is  possible. 

•  Adaptive  meta-design:  The  design  concept  and  requirements  are  beyond  the 
bounds  of  current  experience  but  appear  to  be  similar  in  many  respects  to  a 
situation  for  which  a  methodology  is  available.  It  appears  that  a  nominal 
modification  of  the  existing  methodology  may  suffice  for  showing  feasibility 
and  developing  the  requisite  understanding  of  the  concept  and  constraints. 

•  Original  meta-design:  Either  the  concept  or  one  or  more  of  the  requirements 
are  of  such  a  nature  as  to  preclude  using  an  existing  methodology  or  modifying 
an  existing  methodology.  A  completely  new  methodology  must  be  developed. 

Original  meta-design  will  be  required  in  three  situations.  The  first  is  when  all  of  the 
interactions  and  principles  underlying  how  the  concept  might  work  are  not  fully 
understood.  Concepts  utilizing  advanced  technologies  in  ways  that  are  new,  or  a 


combination  of  technologies  that  have  never  been  brought  together  before,  will  likely  fall 
into  this  category.  In  such  cases,  meta-design  may  result  in  a  decision  plan  in  which 
building  a  prototype  or  many  prototypes  is  essential  to  establish  technical  feasibility. 
Current  analytical  capabilities  may  not  provide  a  satisfactory  level  of  confidence  in  the 
performance  of  the  design. 

Original  meta-design  will  also  be  required  when  the  concept  is  well  understood  but 
the  nature  of  the  user  requirements  are  beyond  the  domain  of  engineering  experience. 
Taking  a  life  cycle  approach  to  the  redesign  of  an  existing  fighter  aircraft  would  be  one 
example  of  such  a  situation-requirements  involving  producibility  and  supportability  have 
not  commonly  been  considered  of  equal  importance  with  those  involving  performance  for 
such  systems  in  the  past. 

The  final  case  requiring  original  meta-design  is  when  the  design  team  is  dealing 
with  new  concepts  and  new  requirements.  In  this  case,  a  two-step  approach  may  be  taken- 
first  finding  a  methodology  that  addresses  the  performance  requirements  and  then  refining 
this  methodology  to  handle  new  requirements  such  as  producibility.  However,  in  some 
cases,  new  concepts  and  new  requirements  must  be  handled  simultaneously.  For  example, 
in  dealing  with  advanced  composite  materials,  performance  and  producibility  must  be 
considered  simultaneously. 

2.  The  Relationship  between  Meta-Design  and  Unified  Life  Cycle 
Engineering 

ULCE,  which  emphasizes  consideration  of  producibility  and  supportability  early  in 
the  design  process,  will  probably  require  original  meta-design  activities.  An  ULCE  design 
process  for  weapon  systems  whose  technologies  and  concepts  are  new  will  require  original 
meta-design,  and  it  is  also  likely  that  original  meta-design  will  be  needed  for  redesign 
efforts  of  existing  systems  in  which  early  consideration  of  producibility  and  supportability 
in  the  design  process  is  beyond  the  scope  of  experience  in  the  weapon  system  design 
community. 

The  relationship  of  meta-design  to  ULCE  is  illustrated  in  Figure  II-5.  This  figure 
shows  a  number  of  components  that  must  come  together  if  an  ULCE  design  process  is  to 
be  realized.  First,  if  the  downstream  Hides  are  to  be  incorporated  into  the  process,  a  means 
for  measuring  and  quantifying  them  must  be  developed.  The  requirements  for  these  Hides 
must  be  defined  in  a  way  that  is  consistent  with  higher  level  customer  requirements  and 
commensurable  with  the  requirements  for  performance,  cost,  and  schedule.  An  appropriate 


description  of  the  design  concept  is  also  needed.  This  description,  along  with  the 
requirements,  represent  the  required  input  for  meta-design. 
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Figure  11-5.  Relationship  of  Meta-Design  to  ULCE 

Before  a  computing  environment  to  support  an  ULCE  design  process  can  be 
developed,  the  key  components  shown  in  Figure  II-5  must  exist.  In  particular,  we  must 
have  an  ULCE  design  methodology.  A  computer  integration  scheme  based  on  an  existing, 
non-ULCE  design  methodology  may  support  the  information  transfers  needed  for  such  a 
methodology  quite  well.  However,  such  a  scheme  will  quite  possibly  be  unsuited  for  an 
ULCE  design  methodology,  in  which  different  information  transfers  are  necessary  due  to  a 
different  or^er  of  design  decisions  needed  for  ULCE. 

A  research  and  development  (R&D)  program  seeking  to  develop  an  ULCE  or 
concurrent  engineering  design  environment  by  first  modeling  the  current  engineering 
design  process  and  then  developing  the  integrating  software  based  on  such  a  model  is  not 
likely  to  succeed,  unless  the  current  design  process  is  an  ULCE  or  concurrent  engineering 
design  process.  If  the  current  design  process  (as  defined  by  its  sequence  of  design 
activities  and  data  flows)  does  not  facilitate  early  consideration  of  producibility  or 
supportability,  an  automated  version  of  this  process  is  not  likely  to.  Data  modeling  efforts 
may  lead  to  some  understanding  of  an  existing  design  process  but  are  unlikely  to  be  of 
much  help  in  development  of  a  new  design  process.  A  new  design  process  must  be  created 
through  original  meta-design,  which  requires  understanding  the  fundamental  engineering 
principles  that  are  driving  the  design  problem.  Once  such  a  process  is  created,  it  can 
certainly  be  represented,  at  some  level  of  abstraction,  by  a  model  of  the  data  or  information 
flows  that  must  take  place  when  the  process  is  executed.  Such  a  model  will  be  an  essential 


building  block  in  the  development  of  a  computing  environment  to  support  execution  of  the 
process. 

Thus,  data  and  information  modeling,  while  important  tools  in  building  computer 
based  design  environments,  are  not  adequate  in  themselves  as  ULCE  development  tools. 
Fundamental  research  in  development  of  new  design  methodologies  is  also  required. 

#  D.  META  DESIGN  AND  THE  ULCE  ARCHITECTURE 

No  unique  ULCE  architecture,  for  an  ULCE  design  process  or  for  an  ULCE 
environment  to  support  that  process,  exists.  An  ULCE  design  methodology  will  be 

^  directly  tied  to  the  design  concept  being  evaluated  and  to  the  specific  requirements  being 

placed  on  the  design.  It  will  also  be  specific  to  the  company  or  organization  in  which  it  is 
implemented  and  to  the  technologies  used  to  implement  it 

As  a  result,  an  ULCE  design  support  system  capable  of  supporting  multiple  design 

#  projects  must  provide  for  an  explicit  meta-design  capability  and  must  be  flexible.  In  the 
top-level  ULCE  procedural  architecture  developed  in  Reference  2  (see  Figure  II-6),  the 
meta-design  capability  is  represented  by  the  middle  box,  the  plan  design  decision  process 
stage.  The  relationship  between  the  procedural  architecture,  as  defined  in  Reference  2,  and 

#  our  representation  for  a  design  process  as  illustrated  in  Figure  II- 1,  is  shown  in  Figure  II- 
7. 
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Figure  11-7.  Design  Process  with  Explicit  Meta-Design  Step 


The  key  difference  between  the  processes  shown  in  Figures  II- 1  and  II-7  is  the 
inclusion  of  the  explicit  meta-design  step.  If  a  capability  for  executing  such  a  step  can  be 
devised,  achieving  a  quantum  improvement  in  design  capabilities  related  to  all  aspects  of 
the  design  (performance,  cost,  schedule,  and  downstream  ility  characteristics)  is  possible. 
As  in  a  flexible  manufacturing  system  (FMS),  which  is  capable  of  rapid  changeover  and 
reconfiguration  to  make  a  wide  variety  of  products,  a  flexible  design  system  (FDS)  such  as 
the  one  envisioned  under  the  ULCE  architecture  will  allow  generation  of  a  wide  variety  of 
designs  in  much  less  time  than  is  now  needed. 

To  make  such  a  flexible  design  system  possible,  a  meta-design  capability  is  needed. 
While  no  generic  meta-design  methodology  is  likely  to  exist  (just  as  a  generic  methodology 
for  ordinary  design  probably  does  not  exist),  analytical  tools  to  support  meta-design 
activities  for  a  wide  class  of  design  problems  can  be  developed.  The  following  chapter 
discusses  the  input  and  output  of  meta  design  in  more  detail  and  shows  through  a  simple 
example  that  an  analytical  approach  to  meta-design  is  necessary.  A  particular  analytical 
approach  that  could  be  implemented  in  a  meta-design  aiding  tool  is  presented  in  Chapter  TV. 
This  approach  can  be  used  to  support  meta-design  in  the  conceptual  phases  of  design 
disciplines  such  as  aircraft  design  and  mechanical  design  and  can  probably  be  also  applied 
to  problems  in  civil  engineering  and  process  engineering  (such  as  chemical  engineering  and 
bioengineering). 


III.  REQUIREMENTS  FOR  META-DESIGN 


Meta-design  is  the  development  of  a  design  decision-making  plan  (a  design 
methodology)  based  on  a  set  of  user  requirements  and  a  particular  design  concept.  Meta¬ 
design  is  delimited  by  the  information  required  to  begin  the  decision  planning  process  and 
the  desired  outputs  or  results.  This  chapter  defines  the  input  and  output  of  meta-design  and 
illustrates  them  through  a  simple  example.  Two  simple  techniques  to  aid  the  meta-design 
process.  Interpretive  Structural  Modeling  (ISM)  and  the  Design  Structure  System  (DSS), 
are  presented  and  applied  in  the  example.  These  simple  approaches  are  based  on  a  subset 
of  the  information  required  for  meta-design,  and  their  limitations  are  discussed.  The 
chapter  concludes  by  identifying  the  need  for  a  more  sophisticated  approach  such  as  the  one 
presented  in  Chapter  IV. 

A.  INPUT  REQUIREMENTS  FOR  META-DESIGN 

Before  beginning  the  meta-design  process,  a  specific  design  concept  must  be 
identified.  The  design  concept  may  be  only  partially  specified,  but  it  must  be  clear  how  to 
state  the  customer's  requirements  in  terms  specific  to  this  concept  (i.e.  how  to  formulate  the 
requirements  in  terms  of  the  design  variables  and  parameters  that  pertain  to  this  concept.) 
This  information  is  developed  as  part  of  the  systems  engineering  process. 

1 .  The  Design  Concept— A  Life  Cycle  Engineering  Interpretation 

If  a  life  cycle  engineering  approach  is  to  be  taken  in  a  design  project,  then  the 
design  concept  must  be  considered  to  include,  in  addition  to  the  product  concept,  elements 
of  the  manufacturing  process,  operational  concept,  support  concept,  and  disposal  concept. 
The  term  system  life  cycle  concept  is  used  in  this  paper  to  denote  this  broader  concept  of  a 
product  along  with  its  required  downstream  processes  and  support  environments. 
Information  that  must  be  developed  for  the  system  life  cycle  concept  includes  the  functions 
to  be  performed  by  the  system,  a  description  of  the  system  itself,  and  information 
describing  how  the  system  actually  performs  these  functions. 


a.  Identifying  Required  Functions  to  be  Performed  by  the  System 

Engineering  system  design  begins  with  a  statement  of  the  need  for  a  system,  a  set 
of  requirements.  Consider  as  an  example  the  following  requirements  for  a  water  storage 
system: 

•  Capacity  must  not  be  less  than  10  cubic  feet 

•  Length,  width,  and  height  must  each  be  greater  than  zero. 

•  Height  must  be  less  or  equal  to  2  feet 

•  Relative  materials  cost  must  not  exceed  6. 

The  statement  of  requirements  for  a  system  must  be  analyzed  to  identify  functions 
that  must  be  performed  by  the  system  to  meet  these  requirements.  The  description  of  these 
functions  should  be  independent  of  the  particular  way  these  functions  will  be  implemented 
in  the  actual  system.  In  the  water  storage  system  example,  the  functions  are  not  stated  in  a 
way  that  specifies  the  geometry  of  the  solution— we  could  have  a  rectangular  tank  or  a 
spherical  tank.  The  shape  of  the  tank  is  an  implementation  detail— an  attribute  of  a  specific 
design  concept  that  fulfills  the  required  functions. 

Functions  are  things  that  must  be  accomplished  by  the  system  to  be  designed. 
Functions  to  be  performed  by  the  water  storage  system  include 

hold  water 


For  the  purposes  of  meta-design,  it  is  useful  to  broaden  the  definition  of  function  to 
include  not  only  those  things  we  want  the  system  to  do,  but  things  we  don't  want  it  to  do 
(unintended  functions).  For  the  water  storage  system,  such  unintended  functions  include 
contaminate  water  allow  water  to  spill 

corrode  allow  water  to  freeze 

allow  water  to  leak  allow  water  to  evaporate. 


It  may  also  be  useful  to  include  as  functions  things  that  are  done  to  the  system  as 
well  as  things  the  system  does.  For  example,  we  might  want  to  include  actions  that  are 
performed  on  the  system  during  production  and  support,  such  as 
build  install  inspect 

test  repair  replace  dispose. 
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Implementation  of  one  function  may  require  implementation  of  several 
subfunctions,  each  of  which  may  require  other  subfunctions.  In  this  case,  a  hierarchical 
decomposition  of  functions  will  result.  This  hierarchical  decomposition  can  become  quite 
extensive  and  complex.  Developing  and  managing  a  large  functional  decomposition  is 
facilitated  by  techniques  such  as  QFD  [Ref.  27]. 

b.  Defining  and  Describing  the  System 

Alternative  system  life  cycle  concepts  can  be  defined  once  an  initial  functional 
decomposition  has  been  developed.  Such  concepts  are  described  by  attributes.  These 
attributes  may  be  numbers,  such  as  height  in  the  case  of  a  rectangular  water  tank,  or  more 
complex  attributes,  such  as  manufacturing  processes  or  support  concepts. 

Attributes  may  have  alternative  values,  each  of  which  leads  to  a  different  instance  of 
a  concept.  For  numerical  attributes,  the  set  of  alternative  values  might  be  a  range  of 
numbers  between  lower  and  upper  limits.  Choices  for  the  values  of  complex  attributes  may 
involve  discrete  alternatives.  For  example,  there  may  be  two  alternatives  for  manufacturing 
process:  manufacturing  process  A,  which  involves  filament  winding  or  lay-up  of 
composite  fabric  on  a  mold,  curing,  and  inspection  operations,  and  manufacturing  process 
B,  which  involves  cutting  parts  from  sheet  metal  stock,  forming  the  parts,  and  welding  or 
fastening  the  parts  to  construct  a  subassembly. 

For  the  water  storage  system,  the  description  of  the  system  life  cycle  concept  might 
include  the  following  attributes: 

capacity  availability  producibility  supportability 

schedule  life  cycle  cost  acquisition  cost  operating  cost 

disposal  cost  manufacturing  process  support  concept  disposal  plan 

general  arrangement  height  length  width. 

The  capacity,  costs,  and  length,  width,  and  height  attributes  are  numerical 
quantities,  while  the  other  attributes,  such  as  manufacturing  process,  support  concept,  and 
general  arrangement,  are  complex  attributes.  Specific  attributes  of  a  concept  may 
correspond  directly  to  a  particular  function  to  be  achieved  by  that  concept.  For  example, 
the  capacity  attribute  for  a  water  storage  system  serves  to  measure  the  degree  to  which  the 
function  "hold  water"  is  performed  by  the  system.  Other  attributes,  commonly  called 
design  variables,  are  indirectly  related  to  functions.  Such  attributes  would  be  the  length, 
width,  and  height  attributes  of  a  rectangular  tank  concept  for  a  water  storage  system. 
These  values,  taken  together,  determine  capacity.  However,  many  combinations  of  values 


for  these  attributes  are  possible  that  will  result  in  the  same  functionality  in  terms  of  capacity 
to  hold  water.  Thus  the  designer  has  a  certain  amount  of  freedom  in  choosing  the  values  of 
design  variables.  This  freedom  will  be  limited  by  constraints  placed  on  the  design  as  part 
of  the  specification  of  requirements  by  the  customer. 

c.  Analyzing  the  Ability  of  the  System  to  Achieve  Functions 

In  engineering  design,  the  manner  in  which  a  function  is  implemented  by  a  design 
concept  is  described  by  relationships  between  the  attributes  describing  the  system  (the 
design  variables)  and  the  attributes  that  represent  the  function  to  be  achieved.  Engineering 
analysis  entails  the  assessment,  using  these  relationships,  of  the  degree  to  which  functions 
are  achieved  and  requirements  met.  These  relationships  are  specified  by  engineering 
theories  and  models  (ET&M)  that  describe  how  the  system  works-how  particular  system 
elements  work  together  to  accomplish  a  given  function  or  group  of  closely  related 
functions. 

The  relationships  specified  by  ET&Ms  are  often  specified  by  mathematical  formulas 
and  equations  but  can  also  be  specified  procedurally— by  giving  an  algorithm  by  which  one 
attribute  can  be  computed  from  values  for  others.  A  computer  program  or  analysis  code  is 
an  example  of  the  latter  method  of  specifying  an  engineering  theory  and  model. 
Algorithmic  specification  of  relationships  is  often  used  when  a  closed  form  mathematical 
specification  is  not  possible. 

An  example  of  a  simple  engineering  theory  and  model  relating  an  attribute  for  a 
function  to  several  attributes  describing  the  system,  is 

capacity  =  length  x  width  x  height 

Another  example,  involving  attributes  for  a  function  and  attributes  for  certain 
subfunctions  is 

life  cycle  cost  =  acquisition  cost  +  operating  cost  +  disposal  cost 

The  level  of  detail  required  in  the  system  description  is  closely  related  to  the  level  of 
approximation  required  to  apply  a  given  engineering  theory  or  model.  Merely  asserting  that 
a  relationship  exists  among  attributes,  without  specifying  this  relationship  in  detail,  may  be 
considered  to  be  engineering  theory  at  a  very  rough  level  of  approximation.  However,  the 
risks  associated  with  basing  decisions  on  such  a  crude  level  of  analysis  are  probably  not 
acceptable.  Additional  definition  of  complex  attributes  of  the  life  cycle  concept  would  be 
needed  before  more  detailed  engineering  theories  and  models  could  be  applied.  For 


example,  support  cost  clearly  depends  on  the  support  concept,  and  producibility  depends 
on  the  manufacturing  process.  Thus,  complex  attributes  for  support  concept  and 
manufacturing  process  would  be  needed  if  accurate  modeling  of  support  cost  or 
producibility  is  desired. 

2.  Formulation  of  User  Requirements  and  Goals 

A  design  must  meet  certain  requirements  and  constraints  that  are  derived  from 
various  factors,  such  as  the  environment  in  which  the  product  will  be  used.  These 
constraints  must  be  appropriately  formulated  in  terms  of  the  attributes  of  the  system  life 
cycle  concept.  An  example  of  a  constraint  would  be  a  limitation  on  certain  dimensions  of 
the  design  (in  the  water  storage  system  example,  such  a  constraint  would  be  the  height 
limitation).  To  be  feasible,  an  instance  of  a  system  life  cycle  concept  must  satisfy  such 
constraints. 

The  customer  may  also  have  certain  desires  that  are  goals  that  the  design  team 
should  seek  to  achieve  but  are  not  strict  requirements.  Design  goals  specify  that  a  particular 
attribute  is  to  be  maximized,  minimized,  or  close  to  a  target  value.  In  a  situation  in  which  a 
design  team  is  developing  a  product  to  compete  in  the  market  place  (such  as  a  new 
automobile),  a  competitive  strategy  is  implemented  through  specific  design  goals  (in  this 
case  provided  by  the  marketing  group)  to  guide  the  design  team. 

Taguchi  methods  [Ref.  28],  in  which  the  design  team  seeks  to  develop  a  design 
minimizing  a  loss  function,  are  one  implementation  of  a  competitive  strategy  in  which  a 
robust  design  is  desired.  The  loss  function  is  a  measure  of  the  loss  the  customer  will  incur 
as  the  product  deviates,  due  to  the  influence  of  noise  factors,  from  a  set  of  target  values  of 
certain  design  attributes.  Choosing  values  for  design  attributes  so  as  to  minimize  the 
expected  loss  function  will  result  in  a  product  that  is  reliable  in  operation--an  increasingly 
important  product  characteristic  to  consumers. 

The  customer  often  has  multiple  goals  that  he  desires  to  achieve  in  the  system. 
ULCE  presents  five  broad  goals  to  the  design  team:  maximize  producibility,  maximize 
supportability,  minimize  cost,  maximize  performance,  and  minimize  development  lead 
time.  Because  simultaneously  achieving  multiple  design  goals  is  often  not  possible,  the 
customer's  ranking  of  requirements  becomes  important.  Through  trade-off  analyses,  the 
design  team  should  seek  to  achieve  a  balanced  design  in  which  each  of  the  goals  is  achieved 
to  the  maximum  extent  possible,  given  the  restrictions  posed  by  the  other  goals  and  the 
customer's  relative  priorities  for  achieving  each  goal. 


Such  a  design  is  a  member  of  the  set  of  Pareto-optimal  designs,  that  is,  designs  in 
which  an  improvement  in  the  value  of  any  specific  design  goal  can  be  obtained  only  at  the 
expense  of  lower  performance  with  regard  to  one  of  the  other  goals.  A  key  factor  in 
achieving  a  balanced  design  is  the  sequence  in  which  design  decisions  are  made.  If 
producibility  is  an  important  design  goal,  for  example,  then  it  should  be  considered  early  in 
the  design  decision  process.  Meta-design  must  provide  a  means  by  which  a  decision 
sequence  leading  to  a  suitably  balanced  design  can  be  developed. 

B .  OUTPUT  OF  A  META-DESIGN  PROCESS 

Planning  a  design  decision-making  process  involves  two  steps: 

•  Identifying  design  decisions 

•  Sequencing  design  decisions. 

Design  decisions  are  groups  of  life  cycle  attributes  that  must  be  co-determined; 
these  attributes  are  tightly  coupled  and  thus  must  be  dealt  with  as  a  group  rather  than  as 
independent  entities.  Design  decisions  may  be  considered  subproblems  of  the  total  design 
problem.  The  set  of  these  decisions,  along  with  the  sequencing  information,  constitutes  a 
decomposition  of  the  total  design  problem.  This  decomposition  is  the  output  of  the  meta¬ 
design  process. 

Sequencing  of  design  decisions  should  be  determined  by  the  customer's 
prioritization  of  requirements  and  design  goals.  Competitive  design  strategies  are  thus 
implemented  through  the  sequence  of  design  decisions.  Design  decisions  made  early  in  the 
process  will  determine  values  for  certain  attributes,  which  will  constrain  the  values  of  other 
attributes  to  be  addressed  in  later  design  decisions. 

Attributes  that  arc  strongly  coupled  with  high-priority  design  requirements  or  goals 
should  be  addressed  in  early  design  decisions  to  ensure  that  the  maximum  flexibility  is 
available  to  the  design  team  to  meet  these  requirements  and  attain  the  goals.  Attributes 
associated  with  lower  priority  requirements  will  generally  not  be  addressed  until  later  in  the 
process,  when  less  flexibility  is  available  and  needed,  since  these  attributes  do  not  affect 
critical  design  requirements. 

The  method  to  be  used  to  determine  the  values  of  the  attributes  in  each  design 
decision  will  not  be  specified  by  the  design  decision  plan.  Although  identifying  the 
techniques  used  to  solve  the  various  design  decision  problems  is  an  important  part  of  meta¬ 
design,  it  will  not  be  addressed  in  this  paper.  The  techniques  used  may  vary  from  strictly 


mathematical  methods  (such  as  numerical  optimization),  to  combinations  of  mathematical 
methods,  computer  models,  hard  modeling  efforts,  and  engineering  judgment 

A  key  part  of  the  design  decision  plan  to  be  developed  by  a  meta-design  process  is 
the  capability  to  handle  the  requirements  negotiation  process.  Requirements  negotiation  is 
necessary  when  the  initial  requirements,  as  stated  by  the  customer,  lead  to  infeasibility. 
When  design  requirements  conflict,  the  design  methodology  must  facilitate  the  design 
team's  understanding  of  the  effects  of  relaxing  the  various  constraints.  Moreover,  the 
methodology  must  allow  design  trade-off  analyses  to  be  conducted  in  an  efficient  manner. 
The  requirement  for  a  design  methodology  to  support  the  requirements  negotiation  process 
sets  fairly  stringent  limitations  on  how  meta-design  is  accomplished  and  the  nature  of  the 
information  needed  to  do  meta-design. 

C .  SIMPLE  APPROACHES  TO  META-DESIGN 

Meta-design  is  closely  related  to  two  techniques  for  decision  planning,  ISM  [Refs. 
29,  30]  and  DSS  [Ref.  32].  These  techniques  are  based  on  a  graphical  representation  of 
the  information  in  the  system  life  cycle  concept  description. 

Various  levels  of  detail  can  be  present  in  different  graphical  representations  of  the 
information.  In  one  representation,  attributes  as  well  as  engineering  theories  and  models 
are  the  nodes  (or  vertices)  of  a  graph.  Figure  HI-1  contains  such  a  graph  for  the  water 
storage  system  example.  An  edge  connects  an  attribute  to  an  ET&M  if  the  attribute  appears 
as  a  variable  in  that  engineering  theory/model. 


ET&M 


life  cycle 
cost 


schedule 


quismon 

cost 


|  ET  &M 1— tiianufacrjrina  . 

T"  i—  process 


producibility 


;  general 
■arrangement 


_  Support  i  pr-Ajufl 
concept  L£Jp£U 

supportability 

[ET&m] "  -  availability 


capacity 


operating 
—  cost 


disposal  ET&M  | 
cost  | 

disposal 

plan 

Figure  111-1.  Graphical  Representation  of  the  System  Life  Cycle  Concept 

Both  ISM  and  DSS  work  with  this  information  in  a  reduced  form,  a  directed  graph, 
which  is  obtained  by  eliminating  the  nodes  corresponding  to  engineering  theories  and 
models.  Engineering  theories  and  models  are  represented  indirectly  in  the  directed  graph 
by  drawing  an  arrow  (directed  edge)  from  an  attribute  A  to  another  attribute  B.  The 
direction  of  this  arrow  indicates  that  B  is  to  be  determined  from  A.  A  directed  graph 
corresponding  to  the  water  tank  example  is  shown  in  Figure  ID-2. 
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Figure  111-2.  Directed  Graph  Representation 


The  graphs  in  Figures  HL-1  and  HI-2  represent  abstractions  of  the  information 
contained  in  the  system  life  cycle  concept,  in  that  they  contain  only  a  portion  of  the 
•  information  in  the  total  concept  description.  For  example,  the  complete  description 

specifies  that  life  cycle  cost  is  the  sum  of  acquisition,  operating,  and  disposal  costs,  while 
Figure  III-l  indicates  only  that  some  relationship,  defined  by  an  engineering  theory  and 
model,  relates  these  quantities;  the  specific  nature  of  the  relationship  is  not  specified  in  the 
£  graph.  Thus,  a  meta-design  procedure  based  on  a  graphical  representation  will  only 

depend  on  the  topological  structure  of  the  system  life  cycle  concept,  not  on  the  actual 
analytical  details  of  the  concept.  Such  a  procedure  may  not  yield  a  workable  design 
decision  plan,  as  is  shown  in  the  following  paragraphs. 


•  The  directed  graph  obtained  in  Figure  HI-2  also  depends  on  the  directions  chosen 
for  the  arrows  used  to  represent  the  engineering  theories  and  models.  Assigning  directions 
to  the  arrows  amounts  to  imposing  a  precedence  relationship  on  the  attributes  in  the  system 
life  cycle  concept  The  implications  of  the  need  to  assign  such  a  relationship  is  to  be 

•  addressed  after  the  discussions  of  ISM  and  DSS  that  follow. 
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1 .  Interpretive  Structural  Modeling 

ISM  allows  one  to  structure  a  decision-making  problem  based  on  input  represented 
by  a  directed  graph  (the  ISM  problem  structuring  technique  is  described  in  Reference  29). 
To  illustrate  the  ISM  recMique  we  shall  apply  it  to  structure  the  directed  graph  of  Figure 

m-2. 

The  first  step  of  the  ISM  problem  structuring  method  is  to  identify  all  of  the  nodes 
of  the  directed  graph  that  are  terminal,  that  is,  no  arrows  emanate  from  these  nodes.  In 
Figure  III-2,  these  nodes  correspond  to  life  cycle  cost,  schedule,  producibility, 
supportability,  availability,  and  height.  Once  these  nodes  have  been  identified,  they  are 
placed  at  the  top  level  of  the  restructured  graph,  ISM  Level  1,  as  shown  in  Figure  DI-3. 

ISM  Level  1 

“  schedule  producibility  supportability  availability  height 

Figure  !!l-3.  Level  1  of  Interpretive  Structural  Modeling  Approach 

A  new,  reduced  graph  is  then  constructed  by  removing  these  nodes  (and  all  the 
arrows  incident  on  them)  from  the  original  graph.  This  reduced  graph  is  shown  in  Figure 
m-4.  Some  other  nodes  will  now  be  terminal  in  the  reduced  graph.  In  the  examnle,  these 
nodes  correspond  to  acquisition  cost,  operating  cost,  and  disposal  cost.  These  nodes  are 
placed  at  Level  2,  as  shown  in  Figure  IH-5.  The  process  is  iterated  until  no  nodes  remain. 
In  the  final  step,  arrows  are  added  to  the  structured  graph  wherever  they  occurred  in  the 
original  graph,  as  shown  in  Figure  IH-5. 

ISM  has  been  applied  to  design  problems  [Refs.  30,  31]  and  has  been  found  to  be 
useful  in  clarifying  relationships  among  elements  of  the  design  problem.  For  our  example, 
a  design  strategy  might  be  to  balance  measures  of  producibility,  life  cycle  cost,  and 
supportability  with  availability  (as  a  performance  metric  for  the  water  storage  tank)  and 
schedule,  while  satisfying  the  requirement  that  the  height  be  no  greater  than  2  feet.  All  of 
these  considerations  have  found  their  way  to  ISM  Level  1  in  the  problem  structuring 
process.  It  is  also  clear  from  the  structured  graph  of  Figure  HI- 5  that  acquisition,  disposal, 
and  operating  costs  are  intermediate  quantities  in  that  they  appear  at  neither  the  lowest  nor 
the  highest  level  of  the  structured  graph.  Of  course,  we  may  wish  to  constrain  intermediate 
quantities  such  as  acquisition  cost,  and  nothing  in  the  ISM  problem  structuring  precludes 
this  possibility.  Finally,  the  considerations  appearing  at  the  ISM  Levels  3  and  4  tend  to  be 
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the  life  cycle  concepts,  such  as  the  manufacturing  process,  support  concept,  and  general 
arrangement,  which  an  implementation  team  can  manipulate  to  influence  the  objectives  and 
constraints  at  ISM  Levels  1  and  2. 
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Figure  111-4.  Directed  Graph  with  Level  1  Nodes  and  Arrows  Removed 
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Figure  111-5.  Final  Results  of  Interpretive  Structural  Modeling 


Design  decision  planning  results  in  groupings  of  the  design  variables  into  decision 
elements  and  sequencing  of  the  decision  elements.  For  example,  the  attributes  at  a  given 
ISM  level  are  decoupled  from  other  attributes  at  the  same  level.  If  such  decoupling  is 
desired  in  the  decision-making  process,  the  ISM  levels  can  be  identified  as  design  decision 
stages.  Presumably,  the  sequence  of  decisions  would  follow  the  directions  of  the  arrows, 
that  is,  ISM  Level  4  would  be  solved  first,  and  ISM  Level  1  would  be  the  last  decision. 

2 .  Design  Structure  System 

DSS  is  based  on  the  idea  that  feedback  iterations  should  be  reduced  or  eliminated  in 
a  workable  decision  sequence.  In  the  DSS  approach  [Ref.  32],  the  directed  graph  is 
represented  by  an  adjacency  matrix,  as  shown  in  Figure  HI-6,  or  by  an  N2  matrix  [Refs. 
33,  34]  as  shown  in  Figure  III-7.  A  directed  graph  is  represented  as  an  adjacency  matrix 
by  indexing  the  nodes  of  the  graph  with  integers  { 1,  2,  3, . . .}.  A  "1"  is  entered  in  the  ith 
row  and  jth  column  of  the  adjacency  matrix  if  there  is  an  edge  in  the  graph  directed  from 
node  i  to  node  j.  The  rest  of  the  entries  in  the  adjacency  matrix  are  zero.  The  N2  matrix 
(Figure  HI-6)  represents  much  of  the  same  information  in  a  more  graphic  style.  The  names 
of  the  nodes  are  entered  as  the  diagonal  elements  of  the  N2  matrix.  An  arrow  directed  from 
a  diagonal  element  i  to  a  diagonal  element  j  is  represented  as  in  the  adjacency  matrix,  except 
that  the  l's  are  replaced  by  circles,  and  lines  are  drawn  to  connect  the  circles  to  the 
appropriate  diagonal  elements.  The  zero  entries  of  the  adjacency  matrix  are  omitted  from 
the  N2  matrix. 

Structuring  the  (N2  or  adjacency)  matrix  of  the  design  problem  to  eliminate 
feedback  loops  results  in  a  block-diagonal  structure  (Figure  ID-8).  In  the  simple  example 
of  Figure  III-7,  all  feedback  loops  can  be  eliminated.  In  a  more  complex  decision-making 
problem,  some  loops  may  be  unavoidable.  For  such  an  example,  a  block  diagonal 
structure  can  be  defined  on  the  matrix  with  feedback  loops  within  only  the  blocks  and  all 
connections  between  distinct  blocks  strictly  feeding  forward.  Reference  32  describes  an 
interactive  program  for  defining  a  block-diagonal  structure  on  the  adjacency  matrix 
resulting  in  the  reduction  or  elimination  of  feedback  loops.  Researchers  at  NASA  Langley 
are  currently  experimenting  with  a  design  decision  planning  tool  based  on  these  ideas 
(Refs.  35  and  36). 


Figure  111-7.  N2  Matrix  of  the  Directed  Graph  of  Figure  ill-2. 
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The  blocks  may  be  identified  with  design  decisions.  The  links  between  blocks  then 
specify  an  ordering  of  design  decisions  that  may  be  used  to  establish  a  sequence  of  design 
decisions.  Since  several  decision  sequences  without  feedback  loops  are  possible  for  this 
simple  problem,  any  of  these  decision  sequences  are  compatible  with  the  DSS  philosophy. 
The  decision-making  plan  developed  using  this  algorithm  may  be  reviewed  by  the  design 
team.  Modifications  to  the  decision-making  plan  can  then  be  made  by  changing  the 
directions  of  the  arrows  in  the  directed  graph  representation. 


3.  Limitations  of  Interpretive  Structural  Modeling  and  the  Design 
Structure  System  for  Meta-Design 

As  noted  in  the  preceding  paragraphs,  both  ISM  and  DSS  require  that  a  precedence 
relationship  be  established  among  the  elements  of  the  system  life  cycle  concept.  More  than 
one  precedence  relationship  can  be  established  from  these  elements,  yet  neither  ISM  nor 
DSS  tell  the  design  team  which  of  the  resulting  methodologies  is  to  be  preferred  over  the 
others. 
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Moreover,  a  design  methodology  obtained  from  ISM  or  DSS  may  not  always  lead 
to  a  feasible  design.  Should  the  requirements  not  allow  a  feasible  design,  neither  ISM  nor 
DSS  provide  the  design  team  with  any  information  about  which  requirements  to  relax  to 
obtain  feasibility  or  how  to  structure  trade-off  analyses  to  inform  the  customer  how  to 
modify  the  requirements.  To  illustrate  the  limitations  of  ISM  and  DSS  for  meta-design,  we 
shall  consider  the  following  modification  of  the  water  storage  system  example. 

In  this  example,  we  may  have  three  attributes  (length,  width,  and  height)  and  two 
functions  (capacity  and  relative  materials  cost),  which  are  related  analytically  by  the 
engineering  theory  and  models: 

[capacity]  =  [length]  x  [height]  x  [width] 

[relative  materials  cost]  =  2  ([length]x[width]+[length]x[height]+[ width]  x  [height]) 
Assume  the  customer  has  specified  the  following  design  requirements  and  goals: 

Requirements: 

•  Capacity  must  not  be  less  than  10  cubic  feet 

•  Length,  width,  and  height  must  each  be  greater  than  zero. 

•  Height  must  be  less  or  equal  to  2  feet 

•  Relative  materials  cost  must  not  exceed  6. 

Goals:  Maximize  capacity,  minimize  relative  materials  cosl 

Note  that  the  design  concept,  functions,  system  attributes,  and  engineering  theories 
and  models  have  been  specified  in  the  statement  of  this  design  problem.  Thus,  this 
problem  has  been  posed  at  an  appropriate  point  in  the  system  engineering  process  for  the 
application  of  a  design  methodology.  The  scope  of  the  problem  is  limited,  representing  a 
detail  of  a  life  cycle  engineering  problem,  to  simplify  the  discussion. 

Figure  III-9  shows  the  graphical  relationship  representing  this  design  concept, 
which  is  analogous  to  Figure  IH-1. 
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[capacity]  =  [length]  x  [height]  x  [width] 
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Figure  ill-9.  Full  Graphical  Representation  of  Concept 

Two  alternative  ways  of  representing  this  information  in  a  directed  graph  are  shown 
in  Figure  III- 10. 
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Figure  111-10.  Two  Directed  Graph  Representations  for  Concept  In  Figure  MI-3 


These  two  graphs  correspond  to  two  different  design  methodologies:  • 


Methodology  A 

1 .  Determine  length,  width,  and  height 

2.  Apply  • 
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[capacity]  =  [length]  x  [height]  x  [width] 
to  determine  capacity. 

3 .  Apply 

[relative  materials  cost]  =  2([length]x[width]+[length]x[height]+[width]  x  [height]) 
to  determine  relative  materials  cost. 


Methodology  B 

1 .  Fix  capacity,  relative  materials  cost  and  height 

2.  Solve 

[length]  x  [height]  x  [width]  =  [capacity] 

for  width, 

[width]  =  [capacity]/([height]  x  [length]). 

Substitute  this  relationship  into  the  equation 

[relative  materials  cost]  =  2([length]x[width]+[length]x[height]+[width]  x  [height]) 

and  solve  for  length. 

The  two  methodologies  derived  from  the  directed  graphs  in  Figure  HI-9  have 
significant  limitations.  For  example,  from  the  directed  graph  of  methodology  A,  we  see 
that  unless  the  correct  values  for  the  attributes  length,  width,  and  height  are  known, 
meeting  the  relative  materials  cost  and  capacity  requirements  without  iterating  the  decision¬ 
making  process  is  difficult,  if  not  impossible.  Methodology  A  does  not  specify  such  an 
iterative  strategy,  so  undertaking  this  methodology  would  be  risky. 

The  directed  graph  of  methodology  B  indicates  that  we  should  be  able  to  determine 
the  design  variables  length  and  width  from  the  requirements  for  cost,  capacity,  and  height, 
the  requirements.  However,  beginning  with  relative  materials  cost  =  6,  capacity  =  10,  and 
height  =  2  (which  would  certainly  appear  to  meet  the  design  requirements),  we  can  show 
that  no  real  solution  exists  for  width.  Thus,  the  initial  design  decision  setting  values  for 
cost,  height,  and  capacity  as  specified  in  the  methodology  results  in  infeasibility  in  a 
subsequent  decision. 

The  directed  graph  representation  reveals  no  indication  of  this  problem.  In  fact,  the 
directed  graph  indicates  that  methodology  B  is  well  matched  to  the  water  tank  design 
problem.  This  example  shows  that  determining  whether  a  design  methodology  will  lead  to 
feasible  designs  using  only  the  information  in  the  directed  graph  representation  is  not 
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possible.  We  must  retain  the  analytical  information— originally  discarded  when  we  went  to 
the  directed  graph  representation— to  determine  whether  the  methodology  corresponding  to 
the  graph  will  lead  to  a  feasible  design.  Specifically,  we  need  the  analytical  content  of  the 
engineering  theories  and  models  to  bring  feasibility  into  the  evaluation.  The  connectivity 
information  contained  in  the  directed  graph  representation  is  simply  not  adequate  for  this 
task. 

No  feasible  designs  satisfy  the  requirements  as  stated  by  the  customer  in  this 
example,  which  is  a  common  situation  in  real  design  efforts.  The  requirements,  as  stated 
originally  by  the  customer,  conflict.  In  such  a  situation,  the  major  issue  the  design  team 
face  is  providing  useful  feedback  to  the  customer  regarding  the  possible  trade-offs  that  may 
be  made  among  the  major  goals,  which,  in  this  case,  are  those  for  capacity  and  relative 
materials  cost  Neither  the  ISM  nor  the  DSS  approaches,  based  on  simple  directed  graphs, 
provide  the  team  with  adequate  information  to  do  this. 

The  next  chapter  presents  a  method  for  analyzing  the  engineering  theories  and 
models  to  aid  in  developing  a  design  decision-making  process  that  does  converge  to  a 
balanced,  feasible  design,  if  one  exists.  The  method  also  assists  the  team  in  performing 
trade-off  analyses  in  support  of  the  requirements  negotiation  process  in  the  case  where  the 
initial  requirements  conflict.  This  method  provides  a  powerful  technique  for  systematically 
evaluating  the  capability  of  a  design  methodology  to  support  life  cycle  engineering. 


IV.  AN  APPROACH  TO  THE  SYNTHESIS  OF  DESIGN 

METHODOLOGIES 


This  chapter  presents  a  systematic,  analytically  based  approach  for  developing 
design  methodologies.  This  approach  has  two  principal  elements: 

•  A  framework  provided  by  optimization  theory  that  allows  the  convergence  of 
design  methodologies  to  be  assessed 

•  Specific  criteria  that  can  be  used  as  guidelines  in  synthesizing  design 
methodologies. 

Two  results  from  optimization  theory  form  the  foundation  for  the  methods 
presented  in  this  chapter.  These  results  allow  proof  of  convergence  of  a  sequence  of 
design  decisions  to  a  balanced,  feasible  design.  The  criteria  that  guarantee  convergence  are 
outlined  in  this  chapter.  The  underlying  mathematical  theory  behind  the  results  presented  in 
this  chapter  is  contained  in  Appendix  B. 

We  go  on  to  develop  an  interesting  application  of  these  ideas.  The  water  storage 
tank  example,  introduced  in  Chapter  III,  is  taken  up  once  again.  We  now  approach  the 
water  storage  tank  design  problem  as  a  problem  in  design  methodology  synthesis.  We 
discuss  alternative  problem  formulations,  and  identify  the  need  for  a  "requirements 
negotiation  subproblem". 

It  is  not  possible  to  meet  all  of  the  requirements  imposed  on  the  water  storage  tank 
design.  Thus,  the  requirements,  scaled  and  formulated  as  goals,  become  multiple 
objectives  in  a  Pareto-optimization  (requirements  balancing)  problem.  In  the  Pareto- 
optimization  formulation,  the  objective  function  is  a  weighted  sum  of  the  conflicting 
multiple  objectives.  The  weighting  factors  can  be  interpreted  as  a  relative  prioritization  of 
the  conflicting  requirements.  A  solution  of  the  corresponding  optimization  problem  for 
fixed  values  of  the  weighting  factors  is  called  a  Pareto-optimal  design.  Pareto-optimal 
designs  are  also  characterized  by  the  statement  that  we  cannot  move  closer  to  achieving  any 
of  the  goals  without  moving  further  away  from  at  least  one  of  the  other  goals. 


Since  the  Pareto-optimal  designs  are  parameterized  by  the  weighting  factors  or 
relative  prioritizations,  they  form  a  manifold  in  the  design  space  with  each  point  defined  by 
the  solution  of  an  optimization  problem.  Exploration  of  this  design  space  can  be 
prohibitively  expensive  if  the  solution  of  the  optimization  problems  is  costly.  Instead,  we 
propose  a  technique  that  allows  us  to  determine  the  entire  family  of  Pareto-optimal 
solutions  explicitly  from  the  solutions  to  a  finite  number  of  optimization  problems,  one 
corresponding  to  each  of  the  conflicting  objectives.  This  technique  is  applied  to  the 
requirements  negotiation  subproblem  for  the  water  storage  tank  design  process. 

The  idea  is  to  negotiate  goals  and  priorities  with  the  customer,  based  on  what  can  be 
achieved  by  the  optimally  balanced  design.  The  difficulty  in  complex  design  problems, 
such  as  those  encountered  in  aerospace  systems  design,  is  that  these  negotiations  must  be 
carried  out  without  explicitly  solving  the  design  problem  beforehand.  In  dealing  with  a 
simple  design  problem  such  as  the  water  storage  tank,  one's  natural  inclination  is  to  find 
the  complete  solution  to  the  problem,  and  then  to  parameterize  that  solution  to  present  the 
information  needed  to  support  requirements  negotiation.  However,  there  is  an  important 
difference  between  the  water  storage  tank  example  and  design  problems  in  the  life  cycle 
engineering  of  complex  systems:  closed  form  solutions  rarely  exist  for  complex  problems. 
The  development  of  the  water  storage  tank  example  in  this  chapter  has  been  guided  by  the 
principle  that  the  methods  used  to  solve  this  simple  problem  must  be  applicable  to  the 
solution  of  complex  problems  in  life  cycle  engineering.  The  requirements  must  be 
negotiated  before  we  seek  the  optimal  design.  This  allows  us  to  control  the  risks  associated 
with  investment  in  design  development  before  a  workable  set  of  requirements  has  been 
established. 

A .  FORMULATION  OF  THE  DESIGN  PROBLEM 

Once  a  system  life  cycle  concept  has  been  chosen,  the  design  decision-making 
problem  can  be  formulated  as  a  Pareto-optimization  problem: 

minimize:  Z  a>r  fr(X) 

Subject  to:  g(X)  £  0 

h(X)  =  0, 

where  X  is  a  vector  of  design  variables  (assumed  to  lie  in  a  compact  subset  of  Rn),  fr(X) 
are  design  goals  or  objectives,  and  g(X)  and  h(X)  are  vector  functions  of  the  vector  X  that 
represent  requirements  or  constraints.  The  tDr  are  relative  prioritizations  of  the  design  goals 
or  objectives:  Z  cor  =1.  This  formulation  represents  a  translation  of  the  customer’s  ranked 
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requirements  and  goals,  via  the  engineering  theories  and  models  underlying  the  design 
concept,  into  a  mathematical  statement  of  the  design  problem. 

Complex  design  problems  are  almost  always  solved  using  some  form  of 
decomposition.  Decomposition  can  be  brought  into  the  problem  formulation  by  breaking 
up  the  vector  of  design  variables  into  subvectors  x,.  If  we  arrange  the  elements  of  the  the 
vector  X  in  an  appropriate  sequence  of  these  xfs,  we  obtain  a  decomposition  of  the  vector 
X  into  the  vector  (xi,X2, . . . ,  xn). 

A  design  decision  process  is  defined  in  this  context  as  a  set  of  design  decisions 

{Di,D2,  ....  Dn}, 

where  each  decision  Ds  can  be  viewed  as  a  subproblem  determining  a  subvector  of  the 
design  variables  xs: 

Subproblem  Ds: 

minimize:  2  cor  fr(xi,X2,  .  .  .,  xs, .  .  .,  xn) 

Subject  to:  gs(xi,X2 . xs _ _  xN)  £  0 

hs(xi,X2, .  . xs . xn)  =  0, 

xs  varies  in  the  solution  of  this  subproblem.  However,  all  of  the  other  subvectors 
xt,  t  *  s,  are  fixed,  either  at  an  initial  value  (baseline  design),  or  at  a  value  determined 
through  solution  of  a  decision  element  sequenced  before  Ds.  The  constraint  vectors  gs  and 
hs  are  formed  by  deleting  constraints  in  which  xs  does  not  appear  from  the  original 
constraint  vectors  g  and  h.  The  subproblem  will  be  an  optimization  problem  if  xs  is 
explicit  in  one  or  more  of  the  multiple  objectives  fr.  If  not,  the  subproblem  reduces  to  a 
problem  of  finding  a  feasible  solution  to  the  equality  and  inequality  constraints  (a  feasibility 
problem).  These  subproblems  are  identified  with  design  decisions.  We  approach  the  study 
of  the  design  decision-making  process  by  analyzing  these  decompositions. 

Two  choices  are  involved  in  synthesizing  a  design  methodology  to  solve  the  Pareto- 
optimization  problem: 

•  How  to  group  the  design  variables  into  design  decisions:  which  of  the 
set  of  design  variables  will  constitute  each  xj?  (choice  of  a 
decomposition) 

•  How  to  sequence  (order)  these  design  decisions—what  ordering  will  we 
place  on  the  Xj’s  in  the  vector  (xi,X2, . . . ,  xn)?  Which  subset  will  be 


addressed  first,  second,  and  so  on?  Which  decisions  can  be  made 
concurrently? 

A  design  decision  process  must  meet  various  criteria.  The  most  important  criterion 
is  that  the  sequence  of  design  decisions  must  produce  a  design  that  balances  the  design 
goals  and  meets  the  design  requirements  (constraints)  with  a  minimum  of  iteration. 

Formulating  the  problem  in  terms  of  optimization  is  important  because  it  provides  a 
theoretical  framework  for  studying  alternative  design  decision  processes.  In  particular, 
the  analytical  notions  of  convergence  and  rate  of  convergence  can  be  introduced  to  provide 
quantitative  means  of  evaluating  the  feasibility  and  efficiency  of  a  design  decision  process. 

Note  that  formulation  of  the  problem  in  terms  of  optimization  theory  does  not  imply 
that  the  problem  must  be  solved  by  numerical  optimization  methods.  The  approach  of  this 
paper  utilizes  results  from  optimization  theory  to  aid  in  sequencing  a  set  of  smaller 
problems  to  solve  a  large  design  problem.  While  these  subproblems  are  formulated  as 
optimization  or  feasibility  problems,  the  details  of  how  these  smaller  problems  are  to  be 
solved  are  not  important  in  this  approach.  This  is  a  consequence  of  the  fact  that  the 
approach  given  here  is  based  on  the  Karush-Kuhn-Tucker  (KKT)  conditions,  which 
depend  only  on  the  problem  formulation.  The  KKT  conditions  are  logically  completely 
independent  from  the  technique  used  to  solve  the  problem.  Thus,  methods  other  than 
numerical  (or  even  graphical)  optimization,  including  engineering  judgment,  could  be 
applied  to  yield  solutions  to  these  problems,  as  long  as  the  solutions  can  be  interpreted  as 
being  optimal,  at  least  for  the  Pareto  balancing  problem.  In  fact,  for  life  cycle  engineering 
problems,  other  methods  are  likely  to  be  necessary,  due  to  need  to  deal  with  uncertainty 
and  judgmental  factors  when  considering  many  downstream  design  characteristics.  The 
approach  presented  here  is  applicable  to  any  design  problem  that  can  be  posed  as  a  balanced 
design  problem  (that  is,  a  Pareto-optimization  problem). 

Meta-design  consists  of  two  components:  synthesis  and  analysis.  We  address  both 
of  these  components.  We  will  first  discuss  analysis,  and  then  show  how  the  analysis  tools 
presented  here  can  be  used  to  aid  in  synthesis  of  better  design  methods. 

B  .  OPTIMIZATION  THEORY  FRAMEWORK 

The  issues  to  be  addressed  in  analyzing  the  output  of  a  meta-design  process  (a 
design  decision  process)  are  whether  the  process  converges  to  a  feasible,  balanced  solution 
of  the  original  problem,  and  if  so,  how  much  iteration  is  required  to  arrive  at  this  solution 


(how  efficient  is  the  process?).  Optimization  theory  provides  several  concepts  that  allow 
these  questions  to  be  addressed,  which  include  the  following: 

•  Conditions  for  maintaining  feasibility 

•  Necessary  conditions  for  a  design  to  be  optimal,  and 

•  A  technique  for  quantifying  the  effect  of  changing  problem  parameters 
on  the  optimal  value  for  a  design  goal,  subject  to  feasibility.  Problem 
parameters  are  design  quantities  that  are  determined  by  considerations 
outside  the  scope  of  a  particular  design  problem. 

In  the  context  of  a  design  decision  process,  problem  parameters  consist  of  design 
variables  that  are  treated  as  fixed  in  a  particular  subproblem  of  a  design  decomposition. 
These  variables  appear  in  other  subproblems  that  have  been  addressed  prior  to  the 
subproblem  currently  being  addressed. 

The  conditions  for  maintaining  feasibility  are  straightforward:  the  constraints  g(X) 
must  not  take  on  positive  values,  and  the  h(X)  must  remain  zero.  The  necessary 
conditions  for  optimality,  developed  by  Karush,  and  independently  by  Kuhn  and  Tucker, 
are  somewhat  more  complex.  We  merely  state  these  conditions  here  and  then  use  them  to 
develop  optimal  sensitivity  derivatives,  a  tool  for  quantifying  the  effect  of  changes  in 
problem  parameters  on  the  optimal  value  of  a  design  goal,  subject  to  the  constraints. 

The  KKT  conditions  are  necessary  conditions  for  a  particular  value  X*  for  the 
vector  of  design  variables  X,  to  be  a  constrained  local  minimum.  These  conditions  are 

•  (Feasibility) 

g(X)£0 
h(X)  =  0 

•  (Active  constraints) 

A.j  gj(X)  =  0  j  = 

Xj>  0 

•  (Extremum  of  the  Lagrangian  over  the  primal  subspace) 

9F(co,X)/9xj  +  ZXj9gj(X)/9xi  +  Z|ik5h^X)/9xi  =0  i  =  1 

where  m  is  the  number  of  inequality  constraints,  n  is  the  number  of  design 
variables,  and 


Using  these  conditions,  we  can  develop  an  efficient  method  for  computing  the 
optimal  sensitivity  derivatives  [Ref.  38],  which  we  now  define. 

The  design  decisions  are  related  to  one  another  in  the  following  way.  Suppose 
there  is  a  constraint 

gj(xi,X2, ...)£0 

This  constraint  appears  in  both  design  decision  Di  and  design  decision  D2.  If  Di  is 
to  be  made  before  D2,  we  must  have  an  initial  (baseline)  estimate  for  the  values  of  the 
variables  X2  before  we  can  evaluate  gj(X).  Note  that  this  estimate  need  not  correspond  to  a 
feasible  design.  The  values  of  the  variables  xi,  as  determined  by  solving  Di,  affect  the 
solution  for  D2.  We  say  that  the  design  variables  xj  are  parameters  for  D2,  and  we 
distinguish  between  parameters  and  local  design  variables.  The  X2's  are  local  design 
variables  for  D2.  The  distinction  between  parameters  and  local  design  variables  depends  on 
the  context:  the  xi's  are  local  design  variables  for  problem  Di. 

The  optimal  solution  to  D2  is  found  by  varying  the  local  design  variables  X2.  The 
idea  of  the  optimal  sensitivity  derivative  is  to  evaluate  the  effect  of  changes  in  the 
parameters  xi  on  the  optimal  value  of  the  objective  function  that  can  be  achieved  through 
optimization  within  the  design  decision  element  D2.  Let  F(xi,X2),  the  objective  function 
for  D2,  also  depend  on  a  vector  of  parameters  xi.  Constraints  g2(xi,X2)  and  h2(xi,X2) 
may  also  depend  both  on  the  local  design  variables  X2  and  on  the  parameters  xi.  We  hold 
th.3  parameters  xi  fixed  while  we  solve  D2.  The  optimal  solution  of  D2  with  xi  fixed 
defines  a  function  F*(xj),  the  optimal  value  function.  For  a  fixed  xi,  the  value  of  F*  is 
given  by  the  minimum  of  F  as  X2  is  varied,  subject  to  the  constraints  of  D2.  Since  values 
for  the  local  design  variables  X2  arc  determined  in  the  solution  of  D2,  F*  is  a  function  of  xj 
alone. 

We  want  to  compute  the  derivative  dF/dxi.  subject  to  certain  constraints  placed  on 
this  derivative,  namely 

•  the  constraints  of  the  optimization  subproblem  D2  remain  satisfied  as  xi  is 
varied,  that  is 

g2(X)  *  0 
h2(X)=0 

•  the  solution  remains  optimal  as  the  vector  of  parameters  xi  is  varied. 


We  can  enforce  the  second  restriction  by  requiring  that  the  KKT  conditions  remain 
satisfied.  These  two  restrictions  on  the  derivative  may  require  adjustments  in  the  optimal 
values  of  the  design  variables  X2  to  compensate  for  the  changes  in  the  parameters  x\. 

It  is  difficult  to  strike  a  compromise  between  simplicity  and  precision  of  notation  for 
the  optimal  sensitivity  derivative.  One  approach,  used  frequently  in  the  literature,  is  based 
on  a  notational  distinction  between  the  design  variables  x  and  the  parameters,  p.  Then 
dF/dp  represents  the  optimal  sensitivity  derivative.  We  will  not  need  to  use  the  ordinary 
derivative  in  the  sequel,  so  one  may  hope  that  this  compromise  will  not  lead  to  confusion. 

We  now  compute  the  optimal  sensitivity  derivative 

dF/dp  =  3F/3p  +  2  [3F/3xi][3xi/3p] 

The  function  x(p)  describes  the  changes  in  the  design  variables  that  are  required  to 
compensate  for  the  variation  of  the  parameter  p.  We  could  approximate  the  derivatives 
9xj/9p  by  finite  differences,  solving  the  optimization  problem  for  p,  determining  the 
optimal  solution  x*(p),  and  then  again  for  p  +  Ap,  computing  the  optimal  solution  x*(p  + 
Ap),  and  then  approximating 

3x/3p  ~  [x*(p  +  Ap)  -  x*(p)]/Ap. 

However,  dF/dp  can  be  computed  exactly,  without  solving  the  optimization 
problem  a  second  time.  We  start  by  applying  the  requirement  that  optimality  is  to  be 
maintained,  so  we  must  also  satisfy  the  third  KKT  condition, 

9F/9xj  +  2Xj9gj/9xj  =  0 

Then 


dF/dp  =  9F/3p  -  2  { 2Xj9gj/9xj }  [dxj/dp] 
or,  rearranging  summations, 

dF/dp  =  9F/9p  -  2  Xj{29gj/9xj[dxi/dp] ) 

Now  if  the  active  constraint  set  does  not  change,  and  feasibility  must  be  maintained 
as  p  is  varied,  we  must  ha  e,  for  each  j  =  1, . . .,  m 

dgj/dp  =  9gj/9p  +  2  [3gj/3xi]  [dxj/dp]  =  0. 

Substituting, 

dF/dp  =  9F/9p  +  2  Xj3gj/9p. 

This  formula  is  of  central  importance  for  our  study  of  the  design  process. 
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C.  GUIDELINES  FOR  META-DESIGN  SYNTHESIS 


The  results  of  the  preceding  section  lead  to  an  approach  to  developing  optimal 
design  decision  sequences  that  is  outlined  in  the  following  paragraphs. 

I .  Feasible  and  Optimal  Decision  Sequences 

A  design  decision  Di  can  be  made  before  another  design  decision  D2  if  the  values 
chosen  for  the  design  attributes  in  Dj  do  not  make  D2  infeasible.  For  example,  suppose 
that  xi  is  a  design  variable  to  be  determined  by  decision  Di,  and  X2  is  also  a  design 
variable,  to  be  determined  in  decision  D2.  Suppose  xi  andx2  are  coupled  by  an  inequality 
constraint  g  : 

g(xi,x2, •  •  • )  £  0 . 

In  sequencing  Di  and  D2  we  have  three  alternatives: 

•  Make  decision  Di  before  D2.  xi  will  then  be  fixed  by  Di  and  will  be  a 
parameter  for  decision  D2 . 

•  Make  decision  D2  before  Di.  X2  will  be  a  parameter  in  Di. 

•  Combine  Di  and  D2  into  a  single  decision  element. 

Consider  now  the  case  where  Di  is  sequenced  before  D2.  Solution  of  Di  will  result 
in  a  change  Axi  from  the  initial  value  for  xi.  The  effect  of  this  change  on  the  inequality 
constraint  g  can  be  assessed  with  a  first-order  approximation: 

Ag~  (3g/9xi)Axi. 

Thus  if  (dg/dxi)  and  Axi  are  opposite  in  sign,  Ag  will  be  negative  and  g  will  be 
less  critical  in  making  decision  D2  (in  comparison  with  the  initial  design).  If  (dg/dxi)  and 
Axi  have  the  same  sign,  g  will  become  more  critical  for  D2  if  we  make  decision  Di  first 

Feasible  sequences  for  the  design  decisions  can  be  determined  using  the  directions 
of  proposed  changes  in  the  design  variables  in  each  decision  and  the  signs  of  the  partial 
derivatives  of  inequality  constraints  coupling  two  or  more  decisions  together.  The  criteria 
are: 

F- 1 )  If  D]  does  not  make  (any  of)  the  constraints  of  D2  more  critical,  then 
Di  can  be  sequenced  before  D2. 

F-2)  If  D2  does  not  make  (any  of)  the  constraints  of  Di  more  critical,  then 
D2  can  be  sequenced  before  Dj. 
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If  D’  makes  the  constraints  of  D2  more  critical,  and  D2  makes  the  constraints  of  Di 
more  critical,  combining  Di  and  D2  into  a  single  decision  element  may  be  necessary: 

If  both  F- 1  and  F-2  are  met,  Di  and  D2  can  be  made  concurrently. 

Many  possible  decision  sequences  may  meet  these  criteria.  In  an  extremely  tightly 
coupled  problem,  all  of  the  initial  design  decisions  may  be  combined  into  a  single  design 
decision  by  this  procedure.  All  of  the  decision  sequences  meeting  criteria  F-l  and  F-2  will 
lead  to  feasible  designs.  We  will  next  consider  additional  restrictions  on  the  possible 
decision  sequences,  leading  to  an  optimal,  and  subsequently,  a  Pareto-optimal  or  balanced 
design. 

Determination  of  a  sequence  of  design  decisions  leading  to  an  optimal  design 
requires  an  initial  suboptimization  pass  through  each  of  the  decision  elements.  In  this 
suboptimization  pass,  each  of  the  decisions  in  which  one  of  the  objective  functions  for  the 
design  appears  explicitly  as  a  function  of  the  local  decision  variables  is  solved  in  isolation. 
Parameters  for  each  subproblem,  which  are  in  fact  local  design  variables  for  some  other 
subproblem,  are  fixed  at  initial  baseline  values.  The  results  of  the  suboptimization  pass  are 
then  analyzed  using  sensitivity  of  optimal  solutions  to  problem  parameters.  That  analysis  is 
used  to  establish  whether  an  iteration  of  the  decision-making  procedure  will  progress 
toward  an  optimal  design. 

In  constructing  a  decision  sequence  leading  to  an  optimal  design,  we  again  have  the 
three  alternatives:  place  Di  before  D2  in  the  decision-making  sequence,  place  D2  before  Dj, 
or  combine  them.  Let  f(xi,X2 , . . . )  be  an  objective  function  to  be  minimized  in  both  Di 
and  D2.  If  Di  is  made  before  D2,  then  xi  appears  in  D2  as  a  parameter.  The  sensitivity  of 
the  optimal  solution  to  D2  to  the  parameter  xi  is  df/dxi.  We  know  the  directions  of 
proposed  changes  in  the  design  variables  (from  the  suboptimization  pass),  so  we  can 
determine 

Af~  (df/dxi)  Axi. 

Thus,  if  df/dxi  and  Axi  are  opposite  in  sign,  Af  will  be  negative.  Then  if  Di  is 
made  before  D2,  f  'will  not  increase  during  the  decision  subsequence  {Di,D2}.  Any 
decision  subsequence  in  which  f  will  not  increase  can  form  part  of  an  optimizing  decision 
sequence.  Optimizing  decision  sequences  are  built  up  from  such  subsequences,  with  one 
additional  criterion:  decision  elements  with  df/dxj  =  0  must  be  placed  after  decision 
elements  with  df/dxj  *  0.  The  need  for  this  criterion  emerges  from  consideration  of 
convergence  questions,  discussed  in  Appendix  B. 
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2.  Application  of  Convergence  Guidelines  to  Synthesis  of  a  Design 
Methodology 

Several  alternative  design  methodologies  may  be  available  to  solve  a  given  problem. 
Other  considerations  often  enter  into  the  decision  sequencing  problem,  such  as  controlling 
costs  associated  with  developing  design  definition  or  running  product  development  tests. 
Thus,  in  applying  the  convergence  results  to  synthesize  a  design  methodology,  attempting 
to  provide  a  completely  deterministic  algorithm  for  selecting  a  decision  sequence  does  not 
make  sense.  Instead,  the  following  step-by-step  process  for  constructing  a  design 
methodology  clearly  indicates  the  points  at  which  the  design  team  can  select  among 
alternative  design  methodologies  to  meet  economic,  program  milestone,  product  definition 
technology,  or  test  schedule  constraints.  The  role  of  optimization  theory  is  to  provide  well- 
defined  criteria  that  must  be  met  by  these  alternative  sequences  and  groupings  of  design 
choices. 

Step  0.  Initialization.  Choose  an  initial  design  within  the  variable  bounds 
and  make  an  initial  choice  of  decision  elements. 

Step  1.  Evaluate  each  decision  element  to  determine  an  optimal  solution 
for  that  decision  element  (in  isolation).- 

Step  2.  Identify  possible  feasible  decision  sequences.  If  feasibility 
requires  combination  of  decision  elements,  iterate  with  Step  1. 

Step  3.  Identify  possible  optimal  decision  sequences.  Check 
convergence.  If  solution  is  converged,  stop.  If  optimality 
requires  combination  of  decision  elements,  iterate  with  Steps  1 
and  2. 

Convergence  criterion:  Both  (i)  design  variables  did  not  change 
during  last  solution  pass  and  (ii)  all  optimal  sensitivities  are  zero 
(df/dxi  =  0  for  all  parameters  xi )  must  be  satisfied. 

Step  4.  Select  a  decision-making  sequence  that  is  both  feasible  and 
optimal.  If  D[  is  sequenced  before  Dj,  the  number  of  parameters 
passed  from  Z),  to  Dj  must  equal  or  exceed  the  number  of 
independent  active  constraints  common  to  both  decision 
elements. 

Step  5.  Find  an  optimal  solution  for  each  decision  element  in  sequence. 

Update  the  values  of  all  design  variables  and  iterate  from  Step  2. 

This  procedure  will  converge  to  an  optimal  solution  from  any  initial  design  within 
the  variable  bounds,  provided  that  the  decision-support  procedures  applied  to  solve  the 
individual  decision  elements  do  so.  The  solution  set  for  the  procedure  is  defined  by  the 
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condition  that  all  df/dx,  =  0.  In  Appendix  B,  we  show  that  this  solution  set  is  the  set  of 
KKT  points. 

In  addition,  this  approach  provides  a  highly  efficient  technique  for  finding  all  of  the 
Pareto-optimal  design  solutions.  Pareto-optimal  solutions  minimize  an  objective 

F  =  Z  corfr ,  X  cor  =  1. 

that  is  a  weighted  sum  of  multiple  objectives  that  may  correspond  to  conflicting 
requirements.  To  find  all  of  the  Pareto-optimal  solutions,  one  would  ordinarily  have  to 
solve  an  optimization  problem  for  each  set  of  values  for  the  weights  cOf. 

These  steps  are  not  necessary  if  we  use  the  information  developed  in  the  meta¬ 
design  process.  To  do  so,  we  allocate  the  multiple  objectives,  fr ,  to  different  decision 
elements.  Then,  at  Step  3,  above,  we  have  available  the  optimal  sensitivity  derivatives 

dfr  /dp .  We  define  an  approximation  to  the  Pareto-optimization  problem  having  optimality 
conditions 

dF/dp  (co)  =  0. 

These  conditions  are  identical  to  the  convergence  criteria  for  the  solution  of  the 
exact  Pareto-optimization  problem  using  the  meta-design  solution  procedure.  We  thus 
solve  the  exact  Pareto-optimization  problem  when  we  satisfy  these  conditions.  In 
Appendix  B,  we  prove  that  these  conditions  may  be  satisfied  by  varying  the  relative 
prioritizations. 

D .  APPLICATION  TO  WATER  TANK  DESIGN  PROBLEM 

In  this  section,  we  will  illustrate  the  approach  presented  in  the  preceding  section 
using  the  water  storage  system  example  presented  in  Chapter  III.  In  particular,  we 
consider  three  additional  design  methodologies  for  this  problem.  Our  goal  in  this  example 
is  to  use  a  simple  problem  to  illustrate  the  basic  ideas.  From  one  point  of  view  the  water 
storage  tank  example  is  too  simple:  the  details  of  the  application  of  the  guidelines  outlined 
in  section  C  above  are  trivial  for  each  of  the  design  methodologies  considered  in  this 
section.  A  slightly  more  complex  example  is  considered  in  Appendix  C.  The  development 
of  more  comprehensive  example  applications  of  the  guidelines  for  design  methodology 
synthesis  is  a  topic  for  further  research  efforts. 
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1 .  Design  Methodologies  Based  on  Optimization 

Let  ci  denote  capacity;  C2,  relative  materials  cost;  1,  length  dimension  of  the  water 
storage  tank;  w,  width;  and  h,  height.  Consider  the  following  methodologies  for  solving 
the  water  storage  tank  design  problem. 

Methodology  C 

Solve  the  following  optimization  problem: 
minimize:  (ci/10  - 1)2 

subject  to: 

ci  =  lwh 

2(lw  +  wh  +  lh)  <  C2 

C2  =  6 

C2,l,w,h  >  e  >  0,  h  <  2. 

The  design  vector  decomposition  xi  =  (C2),  X2  =  (l,w,h)  can  be  used  for  this 
problem.  We  then  have  decision  elements 

Ci: 

satisfy:  C2  =  6 

2(lw  +  wh  +  lh)  <i  C2 
design  variables:  C2 
fixed  parameters:  l,w,h 
and 

C2: 

minimize: 

(ci/10  -  l)2 

subject  to: 

ci  =  lwh 

2(lw  +  wh  +  lh)  £  C2 
l,w,h  >  e  >  0,  h<,2 
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design  variables:  ci,l,w,h 
fixed  parameters:  C2 


Since  there  is  a  unique  objective  function  for  the  problem  addressed  by 
Methodology  C,  (ci/1 0-1)^,  we  need  not  define  weighting  factors. 

Methodology  D 

Solve  the  following  optimization  problem: 
minimize:  (C2/6  - 1  )2 

subject  to: 

C2  =2(lw  +  wh  +  lh) 
lwh  >  ci 
ci  =  10 

ci,l,w,h  S  £  >  0,  h  <  2. 


The  design  vector  decomposition  Xj  =  (ci),  X2  =  (l,w,h)  can  be  used  for  this 
problem.  We  then  have  decision  elements 

Di: 

satisfy:  ci  =  10 
lwh  >  ci 

design  variables:  ci 
fixed  parameters:  l,w,h 


and 

D2: 


minimize: 


(C2/6  -l)2 


subject  to: 

C2  =2(lw  +  wh  +  lh) 
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lwh  >  ci 

l,w,h  Se>0,  h  £ 2 

design  variables:  C2,  l,w,h 
fixed  parameters:  ci 

Again,  there  is  a  unique  objective  function  for  the  optimization  problem  addressed 
by  Methodology  D,  (ci/6-1)2,  so  it  is  not  necessary  to  define  weighting  factors. 

Methodology  E 

Solve  the  following  optimization  problem: 
minimize: 

coi  [ci/ 10  - 1]2  +  0)2  [C2/6  - 1]2 

subject  to: 

lwh  >  ci 

2(lw  +  lh  +  wh)  <  C2 

coi  +  0>2=  1 

ci,  C2,  l,w,h  £e>0,  h£2 
031,0)2  >0 


The  design  vector  decomposition  xi  =  (o)  1,0)2),  X2  =  (ci,C2,l,w,h)  can  be  used  for 
this  problem.  We  then  have  decision  elements 

Ei: 

minimize: 


subject  to: 


0)1  [ci /  10  - 1]2  +  0)2  [C2/6  - 1]2 

0)1  +0)2=  1 

0)1, 0)2  >  0 

ci,C2  fixed  parameters 
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and 


E2: 


minimize: 

0)1  [ci/  10  - 1]2  +  0)2  [C2/6  - 1]2 


subject  to: 

lwh  >  ci 

2(lw  +  lh  +  wh)  ^  c2 
ci,  C2,  l,w,h  >  e  >  0,  h  <i  2 
0)i, 0)2  fixed  parameters 

If  we  interpret  some  of  the  requirements  identified  in  the  water  tank  design  problem 
as  goals,  we  can  model  them  in  the  context  of  optimization  theory  as  objective  functions. 
Thus,  the  objective  functions  in  methodologies  C,  D,  and  E  are  stated  as  minimization  of  a 
the  deviation  of  a  product  characteristic  from  a  desired  target  or  goal  value.  Other 
formulations  are  certainly  possible.  For  example,  we  might  state  the  objective  for 
methodology  E  as 

minimize: 

-COlCl/10  +  CD2C2/6, 


minimizing  cost  and  maximizing  capacity.  In  the  case  where  both  requirements  cannot  be 
met  simultaneously,  both  the  direct  minimization  and  goal  formulations  give  similar  results. 
Note  that  the  direct  minimization  formulation  is  preferable  if  it  is  not  known  that  the 
requirements  are  incompatible. 

Requirements  that  cannot  be  relaxed  are  modelled  in  optimization  theory  as 
constraints.  Taking  advantage  of  this,  we  apply  optimization  theory,  specifically 
convergence  theory,  to  assess  the  capability  of  the  remaining  design  methodologies  to  solve 
the  problem.  The  details  of  such  an  approach  are  given  in  Appendix  B,  and  applied  to 
develop  a  design  methodology  for  landing  gear  layout  in  Appendix  C.  The  basic  concepts 
are  illustrated  in  this  chapter.  Again,  we  emphasize  that  this  application  of  optimization 
theory  to  assess  a  design  methodology  is  distinct  from  the  application  of  design 
optimization  methods,  or  more  specifically  numerical  optimization,  as  a  part  of  a  particular 
design  methodology. 
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Optimization  theory  is  applied  to  evaluate  the  suitability  of  a  design  methodology  to 
meet  a  set  of  requirements  by  considering  each  step  in  the  design  methodology  to  be  a 
decision  element  In  the  context  of  optimization  theory,  decision  elements  are  optimization 
or  feasibility  subproblems.  These  subproblems  are  related  to  one  another  by  engineering 
theories  and  models  linking  design  attributes  in  distinct  decision  elements.  In  evaluating 
the  suitability  of  a  design  methodology  to  meet  requirements,  engineering  theories  are 
analyzed  to  determine  the  monotonicity  of  the  relationships  among  attributes  implied  by  the 
engineering  theories  and  models.  Thus,  for  example,  if  width  is  increased  with  length  and 
height  fixed,  an  increase  in  capacity  is  required  to  satisfy  the  engineering  theory 

ci  =  lwh. 

Thus,  capacity  is  monotonically  increasing  with  width  when  the  "capacity"  engineering 
theory  is  enforced. 

In  a  design  methodology  with  multiple  steps,  the  values  of  design  attributes  will  be 
changed  as  decisions  are  made.  The  monotonicity  information  can  be  used  to  determine 
whether  these  decisions  will  adversely  affect  the  feasibility  of  subsequent  decisions.  The 
monotonicity  information  can  also  be  used  to  assess  the  overall  progress  of  the  decision¬ 
making  sequence  toward  an  optimal,  or  alternatively,  toward  a  Pareto-optimal  (balanced) 
design.  Convergence  of  a  methodology  to  a  feasible  design  and  progress  toward  a 
balanced  or  optimal  design  can  be  ensured  by  imposing  certain  criteria  on  the  sequence  of 
decision  elements.  The  simplest  approach  is  to  allow  decision  element  Dj  to  be  sequenced 
before  decision  element  Dj  only  if  the  choices  for  values  of  design  attributes  in  decision 
element  D,  will  not  adversely  affect  feasibility  or  optimality  of  decision  element  Dj. 
Convergence  of  such  an  approach  is  considered  from  a  theoretical  point  of  view  in 
Appendix  B.  Of  course,  such  a  sequence  may  not  be  possible  to  realize  in  practice.  An 
alternative  approach  is  then  to  constrain  prior  decision  elements  so  that  subsequent  decision 
elements  have  feasible  solutions. 

To  illustrate  these  ideas,  consider  methodology  B  of  Chapter  HI.  In  methodology 
B,  choices  for  height,  capacity,  and  cost  are  distinct  decision  elements  that  are  sequenced 
before  a  choice  is  made  for  the  value  of  the  width  design  attribute.  Choice  of  the  width 
attribute  is  in  fact  constrained  by  w  >  0.  Clearly,  it  is  possible  to  choose  values  for  the 
height,  cost,  and  capacity  attributes  that  make  the  width  decision  element  infeasible,  (for 
example,  height  =  2,  cost  =  6  and  capacity  =  10).  Thus,  using  the  concept  that  prior 
decisions  should  not  adversely  affect  feasibility  of  subsequent  decisions,  we  are  able  to 
accurately  identify  one  of  the  limitations  of  methodology  B.  Methodology  B  has  additional 
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limitations.  One  of  these  limitations  is  the  fact  that  methodology  B  does  not  provide  any 
means  to  continually  improve  the  design  in  terms  of  cost  and  capacity  goals  throughout  the 
design  process.  To  evaluate  methodologies  attempting  to  accomplish  such  improvements, 
we  must  consider  optimality,  or  equivalently,  Pareto-optimal  balance  in  addition  to 
feasibility. 

Methodologies  C  and  D  represent  different  approaches  to  the  design  optimization 
problem.  In  methodology  C,  if  we  attempt  to  solve  C2  before  Ci,  we  may  not  be  able  to 
satisfy  the  constraint  C2  =  6.  The  sequence  {Ci,C2}  is  feasible:  once  the  cost  is  fixed  in 
Ci,  the  optimization  problem  C2  has  a  feasible  solution  for  any  value  of  cost  £  6e2.  Since 
the  choice  of  e  is  arbitrary,  the  sequence  {Ci,C2}  is  feasible  for  any  positive  value  of  cost. 
The  analogy  that  methodology  D  is  feasible  if  the  capacity  is  positive  is  valid. 

Do  methodologies  C  and  D  lead  to  optimal  or  balanced  designs?  The  answer  to  this 
question  depends  on  who  defines  optimality.  Optimality  must  be  defined  by  the  customer's 
needs.  Thus,  methodologies  C  and  D  can  be  optimizing  only  when  they  match  the 
customer's  ranking  of  the  cost  and  capacity  requirements.  Methodology  C  provides  the 
maximum  capacity  meeting  the  cost  requirement,  and  methodology  D  delivers  the  minimum 
cost  to  meet  the  capacity  requirement.  This  fact  is  reflected  in  the  sequence  of  design 
decisions.  In  fact,  the  customer  may  need  to  balance  cost  and  capacity  in  some  sense. 
Neither  methodology  C  or  methodology  D  can  address  this  balancing  problem.  Thus,  we 
have  to  reject  methodologies  C  and  D  if  we  wish  to  produce  designs  balancing  cost  and 
capacity. 

Considerable  additional  complexity  is  required  to  fully  address  this  problem  of 
balanced  design,  as  is  illustrated  by  methodology  E.  Methodology  E  calls  for  a  separate 
requirements  ranking  decision  element  (decision  element  Ej)  in  which  relative  weights  for 
the  cost  and  capacity  goals  are  determined.  Incorporation  of  this  decision  element  ensures 
that  methodology  E  will  deliver  balanced  designs.  In  the  second  decision  element  in 
methodology  E,  (decision  element  E2),  we  determine  values  of  cost  and  capacity  goals  that 
result  in  a  feasible  solution  of  the  Pareto-optimization  problem. 

The  optimization  problem  in  methodology  E  is  stated  so  that  we  can  always  find  a 
solution:  even  though  we  may  not  meet  the  cost  or  capacity  goals,  the  design  will  balance 
the  degree  to  which  those  goals  are  achieved,  with  relative  priorities  determined  by  the 
weighting  factors.  Thus,  the  statement  of  methodology  E  ensures  feasibility  in  this 
restricted  sense.  We  conclude  that  methodology  E  is  well-matched  to  the  water  tank  design 
problem.  Unfortunately,  we  have  paid  too  high  a  price  for  this  suitability:  we  must  ask  the 
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customer  to  prioritize  cost  and  capacity  (i.e.,  choose  values  for  the  weighting  factors,  ©0 
without  the  benefit  of  information  about  the  design  relationship  between  achievable  values 
of  cost  and  capacity--a  question  of  comparable  difficulty  to  the  design  problem  itself. 

Perhaps  a  more  practical  approach  is  to  generate  the  cost/capacity  curve  and  relate 
this  curve  to  the  relative  prioritizations.  This  information  can  be  used  in  a  requirements 
negotiation.  Information  to  support  requirements  negotiation  is  most  valuable  before  we 
completely  define  the  design.  Once  we  reach  agreement  on  the  goals  and  their  priorities, 
we  can  then  address  the  design  of  the  water  storage  tank  itself.  Methodology  E  is  not  well 
suited  to  this  expanded  problem.  To  generate  the  cost/capacity  curve  using  methodology  E, 
we  would  have  to  vary  the  relative  prioritizations,  and  execute  a  reoptimization  of  decision 
element  E-2  for  each  set  of  priorities.  Thus,  we  would  have  to  design  many  water  storage 
tanks  before  we  could  negotiate  with  the  customer  on  what  goals  for  the  water  storage  tank 
should  be.  In  more  complex  design  problems,  each  reoptimization,  in  itself,  may  involve 
the  execution  of  a  complete  design  methodology  in  a  decision  element  such  as  E2. 

2.  A  Design  Methodology  to  Support  Requirements  Negotiation 

An  approach  for  efficiently  generating  families  of  Pareto-optimal  solutions  can  be 
developed  by  further  extending  the  application  of  optimization  theory  to  design 
methodologies  consisting  of  separate  decision  elements.  In  an  optimization-based  theory  of 
design  methodologies,  we  can  pose  the  following  question:  how  can  we  generate 
information  to  support  requirements  negotiation  by  executing  relatively  simple  design 
methodologies,  comparable  to  methodology  C  or  D?  This  question  is  answered  by  a 
method  based  on  the  meta-design  technique.  Optimal  sensitivity  derivatives  can  be  used  to 
avoid  having  to  re-execute  the  simple  design  methodology  for  each  combination  of  values 
of  attributes  that  may  be  of  interest  in  the  requirements  negotiation  process. 

These  insights  begin  with  the  observation  that  optimization  theory  can  be  applied  to 
determine  convergence  of  a  sequential  decision-making  process.  Looking  at  the  problem  in 
this  light,  we  establish  the  convergence  of  a  parameter  passing  scheme  that  allows  us  to 
separate  the  multiple  objective  functions,  locating  them  in  distinct  subproblems. 
Convergence  is  ensured  through  the  use  of  optimal  sensitivity  derivatives.  Finally,  we 
show  how  optimality  conditions  for  the  full  Pareto-optimization  problem  are  related  to  the 
optimal  sensitivity  derivatives  of  the  individual  objective  functions  of  the  subproblems. 
The  details  of  this  argument  are  developed  in  Appendix  B. 
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We  illustrate  the  concepts  behind  the  method  by  giving  an  improved  methodology 
for  the  water  tank  design  problem.  Although  this  problem  can  easily  be  solved  explicitly, 
we  solve  the  problem  using  Lagrange  multipliers  and  optimal  sensitivity  derivatives, 
techniques  which  can  be  readily  applied  to  more  complex  problems  in  life  cycle 
engineering.  A  somewhat  more  complex  example,  balancing  development  risk  and 
performance  in  an  aircraft  sizing  problem,  is  worked  out  in  detail  in  Appendix  D. 

We  consider  the  following  methodology  for  developing  design  information  to 
support  requirements  negotiation: 

Methodology  F 

Solve  the  following  optimization  problem  (the  same  problem  as  solved  by 
methodology  E): 

minimize: 


<0i  [ci/  10  - 1]2  +  C02  [C2/6  - 1]2 

subject  to: 

lwh  >  ci 

2(lw  +  lh  +  wh)  <  C2 
coi  +  ©2  =  1 

ci,  C2,  l,w,h  >  e  >  0,  h  <  2 
(01,0)2  £  0 


The  design  vector  decomposition  xi  =  (ci),  X2  =  (C2),  X3  =  (C0i,C02,l,w,h)  can  be 
used  for  this  problem.  We  formulate  decision  elements  as  follows. 


rmmimze: 


fl  =  (ci/10  - 1)2 


subject  to: 


ci  -  lwh  £  0 


design  variables:  ci 
l,w,h  fixed  parameters 


and 
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minimize: 


f2  =  (c2/6-l)2 


subject  to: 

2(lw  +  wh  +  Ih)  -  c2  ^  0 

design  variable:  c2 
l,w,h  fixed  parameters 

F3: 

minimize: 

F  =  0)i  fi°Pt(l,w,h)  +  0)2  f2opt0»w,h) 

subject  to: 

h-2£0 

coi  +  0)2  =  1 

0)i,0)2>0 


where  the  design  variables  are  now:  0)i,0)2,l,w,h.  fi°Pl  and  f2°Pt  are  the  optimal 
values  of  the  objective  functions  for  subproblems  Fi  and  F2,  respectively,  with  l,w,and  h 
fixed. 

Although  methodology  F  is  similar  in  some  ways  to  methodology  E,  there  is  an 
important  difference  in  that  we  have  split  up  the  multiple  objective  functions  and  assigned 
them  to  different  subproblems.  Although  the  sequences  of  design  decisions  which  make 
sense  for  methodology  F  are  somewhat  restricted  (Fi  and  F2  must  be  executed  before  F3  in 
order  to  define  f^P1  and  f2opt),  methodology  F  provides  us  with  a  very  efficient  technique 
for  constructing  the  cost-capacity  curve  as  a  function  of  the  requirements  priorities.  We 
now  work  through  the  solution  of  the  requirements  negotiation  problem  using  methodology 
F. 

The  basic  concept  is  that  we  can  obtain  the  optimality  conditions  for  subproblem  F3 
directly  from  the  solutions  to  subproblems  Fi  and  F2.  Thus,  we  do  not  actually  have  to 
solve  F3.  As  is  shown  in  Appendix  B,  the  formulation  of  F3  is  such  that  the  optimality 
conditions  for  F3  are  the  same  as  the  optimality  conditions  for  the  undecomposed 
optimization  problem  addressed  by  both  methodology  E  and  methodology  F.  Thus,  the 
particular  decomposition  strategy  used  in  methodology  F  allows  us  to  solve  the  Pareto- 
optimization  problem  indirectly,  using  the  solutions  to  two  suboptimization  problems 
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(subproblems  Fi  and  F2).  Although  the  difference  between  this  solution  technique  and 
methodology  E  is  inconsequential  for  the  simple  water  storage  tank  design  problem, 
methodology  F  can  be  applied  to  much  more  complex  design  problems  with  a  few 
relatively  simple  extensions.  It  is  rarely,  if  ever,  practical  to  apply  the  approach  of 
methodology  E  to  complex  design  problems. 

Solution  of  Requirements  Negotiation  Problem  using  Methodology  F. 

The  formulation  of  subproblem  F3  in  terms  of  f^P1  and  f^P1  suggests  the  use  of 
optimal  sensitivity  derivatives.  Thus,  in  applying  methodology  F  to  the  requirements 
negotiation  problem,  the  first  step  is  to  solve  subproblems  Fi  and  F2,  estimating  the 
optimal  sensitivity  derivatives  of  f^P1  and  f2°Pl  with  respect  to  1,  w,  and  h  from  the 
solutions  to  these  subproblems.  To  do  this,  we  need  to  find  the  values  for  the  Lagrange 
multipliers  for  the  constraints  in  which  1,  w,  and  h  appear  explicitly. 


Solving  Fi  to  determine  a  value  for  the  Lagrange  multiplier  of  the  constraint 

gl  *  ci  -  lwh, 

we  note  that  an  optimal  solution  to  this  problem  must  satisfy  the  third  KKT  condition: 
3fi/9ci  +  Xi3g/3ci  =  2(ci/10  - 1)(1/10)  +  h  =  0. 

Then 

Xl  =  (1/5)(1  -  ci/10). 

where  Xi  is  the  desired  Lagrange  multiplier. 

Determining  a  value  for  the  Lagrange  multiplier  of  the  constraint 

g2  =  2(lw  +  wh  +  lh)  -  C2 


appearing  in  subproblem  F2,  we  again  apply  the  third  KKT  condition 


Thus, 


0f2/3c2  +  A.20g/0C2  =  (l/3)(C2/6  - 1)  -  X2  =  0. 


X2  =  (1/3)(c2/6  -  1). 


We  now  have  the  information  we  need  to  solve  subproblem  F3.  The  optimal 
solution  to  problem  2(a)  is  a  function  of  1,  w,  and  h.  Denote  this  function  by  fiopt(l,w,h). 
Compute  the  optimal  sensitivity  derivatives  DifjoP1,  DwflOP1,  and  Dhfi0Pl.  (The  optimal 
sensitivity  derivatives  can  be  computed  from  partial  derivatives  of  the  objective  function 
and  constraints  with  respect  to  the  decision  variables  at  the  optimal  solution.)  To 
emphasize  that  1,  w,  and  h  are  parameters  for  subproblems  FI  and  F2,  denote  them  by 

1  =  pi,  w  =  p2,  and  h  =  P3. 

Use  the  optimal  sensitivity  derivatives  to  construct  an  approximation 
fl°Pt(pi,p2,p3)  ~  fi°Pt(pi0,p20.P30)  +  £  Dp.f^PtApi 
about  the  point  (pi°,P2°.P30)- 

Define  f2opt(Pi,p2>P3)  in  the  same  way,  and  approximate 

f20pt(pl,p2,P3)  ~  f2opt(pi0,P2°,P30)  +  £  Dp.f2optApi . 

Applying  the  technique  of  optimal  sensitivity  derivatives  to  differentiate  the  optimal 
value  of  fi  as  the  parameter  pi  is  varied, 

DPlfiopt  =  5fi/3pi  +  £j  Aj  9gj/9pi  =  A(-wh)  =  (1/5)(1  -  ci/10)(-wh) 

where  A  is  the  Lagrange  multiplier  of  the  constraint  g  =  ci  -  lwh  <  0  in  problem 

2(a). 

In  a  similar  computation,  determine 

Dp/iopt  =  (1/5)(1  -  ci/10)(-lh) 
and 

Dp3fi°pt  =  (1/5)(1  -  ci/10)(-iw) 

Then 

flopKpi,P2,P3) 

~  fioPt(pi°,P20,p30)  +  (1/5)(1  -  ci/10)(-wh)Api  +  (1/5)(1  -  C!/10)(-lh)Ap2 

+  (1/5)(1  -  ci/10)(-lw)AP3. 

Similar  computations  give 

DPlf2opt  =  (1/3)(c2/6-  l)(w+h) 

(the  other  derivatives  are  computed  in  exactly  the  same  way),  and 

f2opt(ho,ci) 

-  f2°Pt(pi0,p20,p30)  +  (1/3)(c2/6 -l)(w+h)Api  +  (l/3)(C2/6 -l)(l+h)Ap2 

+  (1/3)(c2/6  -1)(1  +  w)Ap3 


Using  the  approximations  to  fiopl(,pi,P2»P3)  and  f2opl(pi,P2>P3)>  we  determine 
capacity  =  ci(coi,o)2»Pi»P2.P3)  and  cost  =  C2(coi,Q)2,Pi>P2>P3)  as  solutions  to  the 
minimization  problem  posed  for  subproblem  F3,  which  we  repeat  here. 

minimize: 

F  =  0)i  fiopt(pi,P2,P3)  +  0)2  f2opt(Pl,P2.P3) 

subject  to: 

P3  -  2  <  0 
0)1  +  0)2  =  1 
0)1, 0)2  ^  0 

where  the  design  variables  are  now: 

1  =  pi,  w  =  p2,  and  h  =  P3. 

Optimality  conditions  for  this  problem  are 

3F/3pi  =  Q)i  DPlfiopt  +  0)2  DPlf2opt  =  0 
3F/3p2  =  0)1  DP2fiopt  +  0)2  D^0!51  =  0 
3F/dp3  +  X  =  0)i  Df^fi0^  +  0)2  Dp3f2opt  +  X  =  0 

The  key  to  methodology  F  is  to  fix  the  optimal  sensitivity  derivatives  and  regard 
these  equations  as  determining  values  for  coi  and  C02  that  correspond  to  those  values  of  the 
optimal  sensitivity  derivatives,  allowing  us  to  bring  the  theory  of  Appendix  B  to  bear  on  the 
minimization  problem.  In  Appendix  B,  we  show  that  sequential  parameter  passing 
schemes  of  the  type  exemplified  by  methodology  F  converge  to  the  optimal  solution  of  a 
Pareto-optimization  problem  such  as  the  problem  approximated  in  this  step  (step  4).  The 
benefit  accruing  from  this  approach  is  that  we  can  determine  the  entire  family  of  Pareto- 
optimal  solutions  (corresponding  to  different  values  for  the  C0i's)  using  only 

•  Information  about  the  solution  to  an  optimization  problem  corresponding  to 
each  of  the  objective  functions,  and 

•  Partial  derivatives. 

The  alternative  approach  (methodology  E)  would  require  us  to  solve  a  separate 
optimization  problem  for  each  combination  of  values  of  the  coj's  we  wish  to  consider. 

Continuing  with  the  solution  of  the  optimality  conditions  for  subproblem  F3,  we 
have  5  unknowns: 


coi,  0)2,  1,  w,  and  h, 

and  4  independent  equations  (five  of  which  are  nonlinear): 

0)i  +  0)2  =  1 

(3  optimality  conditions). 

Thus,  we  can  characterize  the  entire  family  of  Pareto-optimal  solutions  by  varying 
one  of  the  parameters.  One  way  to  do  this  is  to  solve: 

9F/dpi  =  o)i  DPlf!°Pt  +  0)2  DPlf2°Pt  =  0 
=  0)i  (1/5)(1  -  ci/10)(-wh)  +  o>2  (l/3)(C2/6  -l)(w+h) 

to  obtain 

0)i  =  (l/3)(C2/6  -l)(w+h)/[(l/3)(C2/6  -l)(w+h)  +  (1/5)(1  -  ci/10)(wh)]. 

We  apply  the  remaining  two  optimality  conditions  to  determine  that  1  =  w  and  h  = 
min  (w,2).  To  present  our  results,  we  return  to  the  engineering  theories  and  models 
relating  cost  and  capacity  to  1,  w,  and  h.  These  determine  the  achievable  values  for  cost 
and  capacity.  The  variables  Ci  and  C2  of  subproblems  Fi  and  F2  refer  to  the  cost  and 
capacity  constraints.  The  difference  between  these  constraints  and  the  achievable  values  is, 
of  course,  the  whole  point  of  requirements  negotiation. 

We  can  vaiy  w,  determining  cost,  capacity  and  coi  as  w  is  v«u-ied.  The  relationship 
between  achievable  capacity,  actual  cost,  and  requirements  prioritization,  0)1  obtained  in 
this  way  is  plotted  in  Figure  IV- 1.  Since  the  cost  and  capacity  requirements  cannot  both  be 
met,  the  customer  must  accept  some  loss  of  capacity,  cost,  or  both.  The  magnitude  of  the 
loss  depends  on  the  relative  prioritization  given  to  achieving  each  of  the  goals.  The  loss  in 
capacity  is  defined  as 

capacity  goal  -  achieved  capacity 

and  represents  how  far  we  are  from  achieving  the  desired  capacity  of  10  ft3.  The  loss  in 
cost  is  defined  as 

actual  cost  -  cost  goal, 

adopting  the  convention  that  losses  are  positive. 

This  information  can  then  be  used  to  negotiate  values  for  the  relative  prioritizations 
coi  and  0)2  =  1  -  coi.  Once  these  values  are  fixed,  the  optimal  values  for  the  remaining 
design  parameters  are  also  determined. 
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In  most  cases,  where  the  problem  posed  in  methodology  E  cannot  be  solved 
explicitly,  this  procedure  will  be  much  more  efficient  than  methodology  E.  This  is  a 
consequence  of  the  fact  that  the  optimization  problem  in  methodology  E  must  be  solved  a 
large  number  of  times,  one  solution  for  each  value  of  ©i,  to  determine  the  effect  of  coi  and 
o>2  on  cost/capacity  relationship,  while  methodology  F  can  generate  the  entire  cost  capacity 
relationship  from  the  solutions  of  a  few  optimization  problems,  one  for  each  of  the  multiple 
objective  functions. 


Figure  iv-i.  "Loss"  of  Cost  and  Capacity  Goals  vs.  Requirements  Priorities  for  a 

Water  Storage  Tank 


3.  Verification  of  the  Methodology  F  Solution  using  Methodology  E. 

The  water  storage  tank  example  is  simple  enough  so  that  an  explicit  solution  using 
the  straightforward,  though  inefficient,  methodology  E  can  be  found.  We  now  illustrate 
•  this  solution,  in  part  to  motivate  the  results  of  Appendix  B,  and  in  part  to  illustrate,  in 

detail,  the  differences  between  methodologies  E  and  F. 


To  use  methodology  E,  we  must  be  able  to  solve  the  optimization  problem: 
minimize: 
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subject  to: 


design  variables: 


coi  [ci/  10  -  l]2  +  o>2  [C2/6  - 1]2 
lwh  >  ci 

2(lw  +  lh  +  wh)  £  C2 
ci,C2,  l,w,h  >0,  h  £  2 


for  fixed  values  of  ©i  and  ©2.  with  ©1  +  ©2  =  1.  The  optimality  conditions  are  as 
follows: 

The  Lagrangian  is: 

L  (x,X)  = 

©1  [ci/  10  -  l]2  +  ©2[c2 /6  -  l]2  +  Xi(ci-  lwh)  +  X2(2(lw  +  lh  +  wh)  -  02)  +  X3O1-2) 
The  design  variables  must  satisfy: 

(i)  dL/dci  =  (l/5)©i[c  1/  10  - 1  j  +  Xi  =  0 

(ii)  dL/dc2  =  (1/3)©2[c2/6  -  1]  -  X2  =  0 

(iii)  dL/dl  =  Xi(-wh)  +  2X2(w  +  h)  =  0 

(iv)  dL/dw  =  Xi(-lh)  +  2^2(1  +  h)  =  0 

(v)  3L/3h  =  Xi(-lw)  +  2X2(1  +  w)  +  X3  =0 

We  can  solve  equation  (i)  for  Xi  and  equation  (ii)  for  X2: 

Xi  =  (-l/5)©i[ci/  10-1] 

X2  =  (l/3)©2[c2/6  - 1] 

Substituting  these  two  expressions  into  equation  (iii),  we  obtain: 

(-  l/5)©i[ci/  10  -  l](-wh)  +  (1/3)©2[c2/6  -  l](w  +  h)  =  0 

Since  we  must  have  ©1  +  0)2  =  1,  we  can  set  ©2  =  1-  ©1  and  solve  this  equation  for  ©1: 

(- l/5)©i[ci/  10  -  l](-wh)  +  (1/3)(1-  ©i)[c2/6  -  l](w  +  h)  =  0 

-  ©i{(l/5)[ci/  10  -  l](-wh)  +  (1/3)[c2/6  -  l](w  +  h)} 

+  (1/3)[c2/6  -  l](w  +  h)  =  0 

©l  =  (l/3)(C2/6  -l)(w+h)/[(l/3)(C2/6  -l)(w+h)  +  (1/5)(1  -  ci/10)(wh)]. 

This  is  precisely  the  solution  delivered  by  methodology  F. 
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E.  CONCLUSIONS 


Analysis  of  convergence  using  optimization  theory  can  be  used  to  guide  the 
synthesis  of  a  design  methodology  delivering  product  specifications  balancing  conflicting 
requirements.  The  applicability  of  the  KKT  conditions  depends  on  the  nature  of  the 
problem  statement  and  is  independent  of  any  technique,  numerical  or  other,  for  solving  the 
problem.  The  distinction  between  the  statement  of  a  design  problem  and  the  techniques  for 
solving  such  problems  is  fundamental  to  our  subject.  In  design,  we  can  pose  many 
problems  as  optimization  problems.  It  is  not  always  practical  to  solve  these  problems  using 
numerical  techniques.  However,  all  complex  design  problems  are  solved  in  practice  using 
some  form  of  decomposition.  Since  the  decomposition  technique  developed  in  this  paper  is 
based  directly  on  the  KKT  conditions,  application  of  this  method  is  not  dependent  on  use 
of  numerical  techniques  for  design  optimization. 

The  methods  of  Appendix  B  can  be  used  to  prove  that  a  sequential  design  process 
will  converge  to  an  optimal  or  balanced  solution.  Thus,  this  approach  can  be  used  to 
extend  the  application  of  optimization  ideas  to  areas  of  design  where  numerical  optimization 
techniques  have  been  difficult  to  apply.  Examples  of  such  areas  include  design  problems  in 
which  rough  approximations  must  be  made  in  the  engineering  theories  and  models.  In 
such  cases,  engineering  judgment,  perhaps  based  on  comparison  of  predictions  made  by 
several  approximate  theories,  is  required  to  determine  values  for  design  variables. 

The  approach  presented  in  this  chapter  also  promises  to  be  useful  in  engineering 
design  problems  having  attributes  that  are  subject  to  uncertainty  or  random  variations.  In 
this  context,  the  results  offer  a  way  to  systematically  extend  the  optimization  methods  of 
Taguchi  to  solve  complex  design  problems  encountered  in  the  development  of  advanced 
technology  systems. 

A  third  area  of  application  of  the  method  is  in  the  development  of  computational 
environments  for  design  using  object-centered  programming  and  constraint  propagation. 
This  idea  is  developed  in  Appendix  A. 

While  the  approach  is  not  dependent  on  use  of  numerical  optimization,  this  is  not  to 
say  that  these  ideas  are  not  highly  relevant  to  problems  of  numerical  optimization.  The 
approach  taken  here  is  particularly  relevant  to  decomposition  techniques  for  solving  a  large 
optimization  problem  by  defining  an  iteration  scheme  on  a  network  of  smaller  optimization 
problems.  The  results  of  Appendix  B  represent  a  first  step  toward  a  convergence  theory 
for  such  decomposition  methods.  It  is  pertinent  to  point  out  that,  in  significant  measure. 


the  recent  advances  in  algorithms  for  numerical  optimization  have  come  about  through  the 
application  of  the  global  convergence  theory  and  analysis  of  asymptotic  convergence  rates. 
Thus,  one  can  hope  to  see  corresponding  improvements  in  the  decomposition  methods 
through  further  development  of  the  theory  along  the  lines  laid  out  in  Appendix  B. 

The  difficulty  of  determining  the  complete  family  of  Pareto-optimal  solutions  to  an 
engineering  design  problem  is  well  known,  as  is  the  value  of  this  information  in  the 
requirements  negotiation  process.  The  method  for  determining  the  entire  family  of  Pareto- 
optimal  solutions  from  the  solution  of  a  finite  number  of  single  objective  optimization 
problems  and  partial  derivatives,  presented  in  this  chapter,  is  particularly  valuable  in  that  it 
represents  an  efficient  approach  to  what  is  normally  a  computationally  intensive  problem. 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  initiatives  noted  in  Chapter  I  have  successfully  defined  the  problem  of  early 
consideration  of  downstream  product  attributes  such  as  reliability,  maintainability, 
supportability,  and  producibility  in  the  weapon  system  design  process.  From  the  point  of 
view  of  the  system  developer,  however,  these  initiatives  have  added  little  or  nothing  to  the 
methods  available  to  solve  complex  life  cycle  engineering  problems.  Initiatives  to  integrate 
CAD/CAE  tools,  pursued  in  the  absence  of  a  design  methodology  describing  how  such 
tools  are  to  be  used  after  integration,  are  unlikely  to  result  in  significant  progress  toward 
realization  of  ULCE.  Research  in  design  methodology  is  crucial  for  the  accomplishment  of 
the  aims  of  life  cycle  engineering. 

Meta-design,  as  defined  in  this  paper,  is  a  systematic  approach  to  the  development  of 
design  methodologies.  Two  existing  approaches  to  meta-design,  ISM  and  DSS,  use  a 
directed  graph  model  of  the  design  problem  as  input .  However,  the  directed  graph  does 
not  contain  sufficient  information  to  allow  development  of  a  methodology  capable  of 
resulting  in  a  balanced,  feasible  design.  Such  a  methodology  usually  requires  as  input  the 
full  analytical  content  of  the  design  problem.  A  similar  problem  faces  the  user  of  QFD, 
another  tool  for  structuring  and  tracking  decision  processes.  To  be  used  successfully  in 
complex,  advanced  technology  systems  development,  QFD  must  be  coupled  with  a  design 
methodology  that  takes  into  account  the  analytical  aspects  of  the  design  problem. 

This  paper  presents  a  technique  for  using  results  from  optimization  theory  to  aid  in 
accomplishing  the  meta-design  process.  This  technique  facilitates  evaluation  of  existing 
design  methodologies  to  determine  the  extent  that  they  will  lead  to  balanced,  feasible 
designs.  The  technique  may  also  be  used  to  support  synthesis  of  new  design 
methodologies. 

In  addition,  a  new  technique  for  developing  design  information  to  support  negotiation 
of  conflicting  requirements  has  been  introduced.  This  capability  is  critical  in  cases  where 
the  initial  requirements  levied  on  the  design  team  conflict,  and  information  must  be 


developed  to  allow  rational  trade-offs.  Simple  methods,  such  as  ISM,  DSS,  and  QFD  do 
not  support  this  activity. 

B  .  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

This  paper  underscores  the  foundational  importance  of  design  theory  and 
methodology  development  for  ULCE.  Development  of  ULCE  design  methodologies  is  a 
research  area  that  has  received  very  little  attention.  Significant  progress  towards 
implementation  of  ULCE  is  not  likely  to  occur  until  this  crucial  area  is  addressed.  The 
concept  of  meta-design  discussed  in  this  paper  is  a  key  element  in  development  of  an 
ULCE  environment  that  represents  a  flexible  design  system.  Such  a  system,  if 
implemented,  could  revolutionize  design  team  productivity  and  design  quality.  In  moving 
toward  such  a  goal,  additional  research  should  be  considered  in  certain  areas. 

First,  the  methods  of  this  paper  should  be  demonstrated  and  evaluated  by  applying 
them  to  a  design  problem  comparable  in  scope  to  the  conceptual  development  of  aircraft 
system.  In  particular,  a  life  cycle  approach  to  this  problem  should  be  formulated  and 
executed  through  application  of  this  methodology. 

Research  into  the  application  of  the  ideas  contributed  by  this  paper  to  product 
development  and  system  management  problems  characterized  by  uncertainty  or  random 
variations  in  the  design  attributes  should  be  also  be  pursued.  An  area  of  considerable 
interest  is  the  integration  of  the  approach  of  this  paper  with  QFD  and  Taguchi  methods  to 
rapidly  develop  robust  designs  for  complex  advanced  technology  systems.  QFD  can  be 
used  to  structure  the  systems  engineering  process  leading  to  development  of  the  input 
information  (the  system  life  cycle  concept)  needed  for  meta-design.  Taguchi  methods,  as 
generalized  by  Tse  [Ref.  24],  can  then  be  applied  as  a  method  for  solving  the  optimization 
subproblems  identified  by  the  meta-design  approach. 

Finally,  the  convergence  theory  developed  in  this  paper  for  decomposition  methods 
of  optimization  should  receive  further  investigation.  Useful  results  concerning  the 
convergence  of  iterative  decomposition  methods  that  are  not  sequential  are  immediately 
accessible  using  the  techniques  developed  here. 
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THE  ROLE  OF  OPTIMIZATION  IN  EMERGING  COMPUTING 
ENVIRONMENTS  FOR  LIFE  CYCLE  ENGINEERING 


This  appendix  explores  the  relationship  between  life  cycle  engineering  methodology 
and  advanced  techniques  for  structuring  and  interpretation  of  computer  programs, 
beginning  with  the  architecture  and  integration  requirements  for  a  unified  life  cycle 
engineering  (ULCE)  design  environment  developed  in  Ref.  A-l.  The  role  of  decision 
planning  and  methodology  development  in  the  life  cycle  engineering  process  is  reviewed 
and  implementation  of  a  life  cycle  engineering  environment  using  object-centered 
programming  is  outlined. 

Advantages  of  the  object-centered  programming  approach  include  the  capability  of 
high-level  programming  languages  for  design  to  represent  design  concepts  in  a  computing 
environment,  the  use  of  instantiation  to  reduce  the  cost  of  generating  design  detail,  and  the 
suitability  of  constraint  propagation  as  a  technique  for  implementing  a  design  methodology 
in  a  computing  environment.  The  effect  of  high-level  languages  and  instantiation  on  the 
cost  of  developing  and  using  computing  environments  for  design  is  discussed. 

Constraint  propagation  is  also  defined  and  the  reasons  why  it  is  appropriate  as  a  tool 
for  implementing  a  design  process  in  an  advanced  computing  environment  are  clarified. 
The  relationship  between  meta-design  and  constraint  propagation  is  presented;  in  an 
advanced  computing  environment  for  engineering  design,  the  design  methodology  defines 
the  computational  agenda  for  constraint  propagation. 

To  develop  product  designs  balancing  a  range  of  life  cycle  requirements,  existing 
techniques  for  constraint  propagation  must  be  extended  to  allow  propagation  of  feasibility 
and  optimality  constraints.  The  techniques  developed  in  this  paper  offer  one  way  to 
accomplish  this  extension. 

A.  INTRODUCTION 

Life  cycle  engineering  involves  an  expanded  scope  in  the  requirements  and  trade-offs 
to  be  considered  early  in  the  design  process.  This  expansion  will  result  in  increased  system 
development  costs.  Early  consideration  of  producibility  and  supportability  requires  a 
corresponding  increase  in  the  number  of  attributes  and  evaluation  criteria.  For  example, 


instead  of  simply  considering  alternative  configurations  for  a  product,  the  elements  of  the 
support  system  and  production  process  must  also  be  considered.  Clearly,  some  additional 
attributes  are  needed  to  describe  alternative  support  and  production  concepts.  It  may  also 
be  necessary  to  define  aspects  of  the  configuration  that  are  not  used  in  the  assessment  of 
system  performance  to  link  the  product  concept  to  the  production  and  support  concepts. 
The  number  of  alternative  life  cycle  concepts,  including  system,  production,  and  support 
concepts,  that  must  be  developed  and  evaluated  to  support  technical  decision-making 
increases  in  proportion  to  the  number  of  attributes.  Generation,  definition,  and  evaluation 
of  design  alternatives  are  the  primary  sources  of  engineering  costs  in  the  early  phases  of 
design.  Thus,  life  cycle  engineering  will  require  increased  up-front  investment. 

Although  funding  levels  for  requirements  definition  and  conceptual  design  are  small 
in  comparison  with  subsequent  investments  in  product  development,  additional  funding  for 
concept  exploration,  concept  definition,  and  demonstration/validation  may  simply  not  be 
available  in  a  competitive  economic  situation.  Even  when  funding  is  available,  not  all 
systems  entering  development  ultimately  reach  operational  capability.  Thus,  it  may  not  be 
possible  to  justify  additional  up-front  costs  associated  with  life  cycle  engineering  on  the 
basis  of  potential  savings  in  life-cycle  costs.  Better  computing  environments  for  design 
offer  one  way  to  reduce  up-front  design  costs  enough  to  make  it  economically  feasible  to 
apply  life  cycle  engineering  to  a  system  development  program  without  requiring  a  change  in 
the  funding  profiles  for  system  development  programs. 

B  .  META-DESIGN:  DECISION  PLANNING  AND  METHODOLOGY 
DEVELOPMENT  IN  THE  LIFE  CYCLE  ENGINEERING  PROCESS 

The  basis  for  meta-design  is  the  principle  that  a  convergent  design  decision-making 
sequence  meeting  all  critical  requirements  is  implicit  in  the  technical  description  of  the 
design  concept.  The  idea  is  to  formulate  a  design  decision  plan  by  extracting  the  design 
process  from  the  design  concept  (Figure  A-l). 


Figure  A-l.  Meta-Design  Concept 


The  problem  structure  information  is  developed  by  the  design  team,  which  includes 
vendor  representatives,  manufacturing  and  support  specialists,  and  specialists  in  various 
engineering  disciplines  such  as  (in  the  case  of  aircraft  design)  aerodynamicists,  operations 
analysts,  and  structural  analysts.  This  is  done  in  the  Generate  Design  Alternatives  step  of 
the  life  cycle  engineering  process  (Figure  A-2). 


Figure  A-2.  Architecture  of  a  Life  Cycle  Engineering  Process. 

Meta-design  is  accomplished  in  the  Plan  Design  Decisions  step,  which  takes  place 
after  design  alternatives  have  been  generated  (and  captured  in  a  representation  of  the 
evolving  life  cycle  concept,  termed  the  Design  in  Progress)  and  before  design  decisions  are 
made.  To  provide  the  information  required  for  meta-design,  a  computing  environment  for 
life  cycle  engineering  must  provide  explicit  representation  of  system  requirements, 
competitive  strategies  (goals),  system  functions,  technical  description  of  system  design, 
production  and  support  concepts,  and  engineering  theories  and  models. 


The  Plan  Design  Decisions  block  of  Figure  A-2  is  expanded  in  Figure  A-3  to  indicate 
how  the  design-in-progress  information  is  used  in  the  meta-design  process.  In  describing 
the  meta-design  process,  we  first  identify  the  elements  of  the  life  cycle  engineering  process 

•  architecture  appearing  in  Figure  A-3,  and  then  proceed  to  discuss  the  process  represented 
by  the  figure.  The  technical  content  of  the  system  life  cycle  concept  is  represented  in  the 
life  cycle  engineering  environment  by  the  Design  in  Progress.  This  technical  content 
includes  product  definition,  process  (manufacturing)  definition,  and  definition  of  support 

•  concepts.  The  Design-in-Progress  is  comprised  of  three  parts:  the  functional 
decomposition  (what  it  does)  ,  the  system  description  (what  it  is),  and  the  engineering 
theories  and  models  (how  it  works).  This  partitioning  is  illustrated  in  Figure  A-4. 
Requirements  and  goals  are  expressed  in  terms  of  the  individual  attributes  within  the 

•  functional  decomposition  and  the  system  description.  The  engineering  theories  and  models 
describe  how  system  elements  work  together  to  accomplish  specific  functions.  This 
information  is  developed  iteratively  in  each  pass  through  the  Generate  Design  Alternatives 
step. 
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The  explicit  functional  decomposition  is  essential  for  linking  support,  production,  and 
vehicle  or  platform  concepts.  The  functional  decomposition  includes  both  intended  and 
unintended  (failure)  functions,  to  the  extent  that  they  are  known  by  the  development  team. 
AH  technical  concepts  relevant  to  the  life  cycle,  including  product  and  process  descriptions 
and  support  concepts,  are  in  the  system  description.  The  engineering  theories  and  models 
are  quite  broad  in  application,  and  include  manufacturing  process  models,  operational 
simulations,  methods  for  evaluating  human  factors  in  maintenance  operations,  and  analysis 
tools  used  in  the  more  performance-oriented  aerodynamics,  structures,  propulsion,  and 
controls  disciplines.  Many  of  the  engineering  theories  and  models  may  require  processes 
for  using  subjective  judgments  of  experts  to  rank  qualitative  design  alternatives  for 
evaluation. 

The  life  cycle  engineering  environment  also  includes  information  about  the  Design 
Decision  Process.  The  life  cycle  engineering  team  create  this  process  as  part  of  the  Plan 
Design  Decisions  step.  This  process  provides  the  interfaces  for  controlling,  tracking,  and 
executing  design  decisions  in  the  Make  Design  Decisions  step  of  the  life  cycle  engineering 
process. 

To  implement  the  Plan  Design  Decisions  step,  meta-design  involves  both  identifying 
design  decision  elements  and  a  sequencing  these  elements  for  execution.  To  identify 
design  decision  elements,  the  connectivity  information  contained  in  the  Design  in  Progress 
is  extracted.  The  nature  of  this  connectivity  information,  for  a  simple  aircraft  design 
example,  is  indicated  in  Figure  A-5.  Engineering  theories  and  models  link  the  functional 
and  system  hierarchy  decompositions. 

Two  important  aspects  of  these  connections  are  evident: 

•  A  single  engineering  theory/model  may  connect  several  attributes  of  the 
functional  and  system  hierarchy  decompositions. 

•  Attributes  of  the  functional  and  system  hierarchy  decompositions  may  be 
connected  by  more  than  one  engineering  theory/model. 

These  two  features  of  the  information  contained  in  the  Design-in-Progress 
representation  connect  the  attributes  of  the  system  concept  to  those  of  the  functional 
decomposition  in  a  complex,  graph-like  topological  structure.  An  example  illustrating  the 
basic  concept  is  shown  in  Figure  A-6.  Here,  the  example  of  Figure  A-5  has  been  extended 
to  indicate  the  connections  present  in  the  Design-in-Progress  before  the  selection  of  a 
power-  or  thrust-generating  propulsive  device  has  been  made. 


Figure  A-3.  Design  Methodology  Development  and  Design  Decision  Planning  in 

the  Life  Cycle  Engineering  Process 


Figure  A-4.  Elements  of  a  Design  Concept 


Function 

Perform  Mission 


Engineering  Theories  Link  Functions  and  System  Elements 


Figure  A-6.  G-dlgraph  Representation  of  Design  in  Progress 

The  structure  shown  in  Figure  A-6  is  not  a  graph  in  the  usual  sense  (see  Ref.  A-2), 
for  the  relationships  may  connect  more  than  two  design  attributes.  Graphs  represent 
binary  relations  (only  two  arguments).  The  Figure  A-6  structure  has  been  described  as  a 
generalized  directed  graph  (G-digraph)  [Ref.  A-3].  The  attributes  of  the  life  cycle  concept 
are  the  vertices  of  the  G-digraph,  and  the  relationships  among  these  attributes  (implied  by 
engineering  theories  and  models)  are  represented  by  directed  edges  (in  the  sense  of  Ref.  A- 
3)  connecting  these  vertices. 
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Design  decision  elements  are  identified  by  combining  attributes  (vertices  of  the  G- 
digraph)  that  must  be  considered  together  to  make  a  design  decision.  Design  decision 
elements  would  normally  be  arranged  to  fit  into  the  structure  of  the  system  hierarchy  and 
subsequendy  the  work  breakdown  structure.  (The  relationships  among  design  decisions  are 
not  always  hierarchical,  however).  Individual  decision  elements  must  also  be  compatible 
with  available  decision  support  tools,  as  indicated  in  Figure  A-3.  The  resulting  design 
decision  tasks  become  part  of  the  Design  Decision  Process. 

Once  the  decision  elements  have  been  identified,  a  sequence  for  making  these 
decisions  is  determined.  The  sequencing  of  the  decisions  must  result  in  a  feasible, 
balanced,  "optimal"  design  with  a  minimum  of  iteration.  In  addition  to  the  connectivity 
information,  considerations  such  as  monotonicity  and  sensitivity,  essentially  analytical  in 
nature,  are  important  from  the  point  of  view  of  converging  the  design  iterations.  This 
information  is  available  in  the  engineering  theories  and  models  of  the  Design  in  Progress. 
(Examples  illustrating  the  use  of  analytical  information  about  relationships  implied  by 
engineering  theories  and  models  to  sequence  design  decisions  are  found  in  Chapter  IV  and 
Appendices  C  and  D  of  this  paper.)  The  decision  sequence  must  be  arranged  to  provide  the 
information  needed  to  support  specific  program  decision  points.  This  sequencing 
information  is  included,  along  with  the  definition  of  specific  decision  elements,  in  the 
Design  Decision  Process  element  of  the  life  cycle  engineering  process  architecture. 

Design  decisions  are  executed  in  the  Make  Design  Decisions  step.  Making  these 
decisions  establishes  specifications  for  system  attributes  and  defines  requirements  for  the 
next  level  of  the  ULCE  process.  Defining  system  functions  to  meet  the  requirements 
emerging  from  the  design  decisions  initiates  a  Generate  Design  Alternatives  step  at  the  next 
level  of  detail  in  the  definition  of  the  system  life  cycle  concept.  The  life  cycle  engineering 
process  iterates  through  levels  of  design  decisions  in  this  way  until  sufficient  technical 
information  has  been  developed  to  support  the  relevant  program  management  (and 
subsequently  operational)  decision. 

We  now  consider  an  approach  to  implementing  a  computing  environment  capable  of 
supporting  this  process  architecture  for  life  cycle  engineering.  This  approach  is  based  on 
the  application  of  advanced  computing  technology. 

C.  EFFECT  OF  EMERGING  COMPUTING  TECHNOLOGY  ON  LIFE 
CYCLE  ENGINEERING 

Advanced  techniques  for  organizing  and  using  computer  programs  make  a  design 
computing  environment  for  life  cycle  engineering  feasible  in  terms  of  the  associated  up- 


front  investment  costs.  The  strategy  is  to  reduce  these  costs  by  using  abstraction  to  manage 
complexity.  Although  procedures  and  data  are  usefully  abstracted  in  design  software, 
perhaps  the  most  important  application  of  the  advanced  computer  programming  techniques 
is  in  the  use  of  metalinguistic  abstraction  and  modularity,  objects,  and  state  [Ref.  A-4]  to 
represent  design  concepts  and  processes.  The  computer  programming  techniques 
discussed  in  this  section  —  object-centered  programming,  instantiation,  and  constraint 
propagation  --  are  applications  of  these  ideas. 

1 .  Object-Centered  Programming  and  Instantiation 

Object-centered  programming  is  a  strategy  for  designing  computer  programs  in  which 
the  structure  of  the  program  is  based  directly  on  the  structure  of  the  system  being  modeled 
[Ref.  A-4].  To  illustrate  the  idea,  consider  an  object-centered  system  for  the  conceptual 
design  of  aircraft.  The  developer  of  the  system  organizes  the  computer  program  using 
wing,  fuselage,  lifting  surface,  mission,  and  other  objects,  instead  of  programs, 
subroutines,  and  functions.  The  immediate  advantage  in  terms  of  productivity  of  the 
product  development  team  is  that  translation  step  (from  concepts  relevant  to  the  engineering 
problem  to  computer  programming  language  constructs)  is  greatly  reduced,  if  not 
eliminated  altogether.  A  representation  of  the  engineering  problem  in  software  that 
corresponds  directly  to  the  structure  of  the  problem  (as  an  engineer  understands  the 
problem)  considerably  enhances  computer  program  readability  and  reduces  the  number  of 
obvious  programming  blunders. 

Additional  advantages  benefit  the  developer/engineer.  In  a  computing  environment 
that  supports  the  object-centered  programming  strategy,  modularity  is  strongly  enforced 
within  the  objects.  Thus,  entire  FORTRAN  programs  can  reside  within  an  object  that 
controls  their  execution.  Procedures  hidden  within  objects  are  sometimes  called  methods 
for  the  object.  Data  can  also  be  stored  in  objects  using  local  variable  names.  Extension  of 
the  capability  of  a  design  system  implemented  using  object-centered  programming  is 
considerably  simplified  because  the  developer  can  program  at  a  very  high  level  without 
considering  the  operating  system  or  memory  management. 

Inheritance  is  often  supported  in  such  a  computing  environment.  Using  inheritance, 
the  developer  can  represent  concepts  common  to  many  objects  using  a  single  object.  Tools 
used  by  many  objects,  such  as  icons  or  windows,  are  often  implemented  as  objects  whose 
properties  can  be  inherited  by  another  object.  This  idea  can  also  be  applied  to  technical 
constructs,  such  as  point-in-space  or  lofted  surface. 


Instantiation  is  usually  considered  to  be  an  essential  part  of  an  object-centered 
programming  system  —  the  object  defined  in  software  by  the  developer  is  a  kind  of  template 
or  prototype  for  individual  instances  of  that  object.  Instances  of  an  object  would  normally 
be  created  by  the  user.  Thus,  the  developer  of  design  software  would  define  a  wing  object, 
representing  the  definition  of  the  wing  technical  concept  in  software,  and  designer/users  of 
the  system  would  define  alternative  wing  designs  by  making  instances  of  the  wing  object. 

The  local  instance  variables  defined  for  an  object  can  have  different  values  bound  to 
them  in  different  instances  of  the  object.  Thus,  wings  with  different  aspect  ratios,  wing 
spans,  airfoil  sections,  or  aft  spar  heat  treatment  processes  can  be  defined  and  managed  as 
the  design  progresses. 

Instances  of  objects  interact  with  each  other  and  with  the  user  by  passing  messages. 
Examples  of  messages  include  requests  from  the  user  to  obtain  or  set  the  value  of  a  local 
variable  or  the  user  or  another  instance  of  some  object  instructing  an  instance  to  execute  one 
of  its  local  methods. 

Some  experience  in  the  development  and  application  of  these  tools  has  been  gained  in 
the  research  projects  described  in  References  A-5,  A-6,  A-7,  A- 8  and  A-9.  Based  on  this 
experience,  informal  estimates  of  the  expected  improvements  in  designer/user  productivity 
have  been  made.  Most  of  the  estimates  of  increases  in  productivity  range  between  a  factor 
of  4  and  12,  although  increases  in  designer/user  productivity  as  great  as  a  factor  of  40  have 
been  estimated.  The  Automated  Airframe  Assembly  Program  (AAAP),  currently  being 
performed  by  Northrop  for  USAF  Materials  Laboratory,  has  provided  preliminary 
examples  of  the  designer/user  productivity  increases,  relative  to  current  state-of-the  art 
CAD  (computer-aided  design)  systems,  that  can  be  achieved  in  detail  design  and 
manufacturing  engineering.  Improvement  of  designer/user  productivity,  in  terms  of  the 
time  to  define  a  model,  by  a  factor  slightly  greater  than  30  is  seen  in  the  results  presented 
in  Ref.  A-9.  Two  conclusions  can  be  drawn  immediately  from  these  preliminary  estimates: 

•  Additional  research  is  needed  to  obtain  and  substantiate  estimates  of  the  effect 
of  advanced  computing  technologies  on  designer/user  productivity  for  various 
types  of  design  problems,  and 

•  Computing  technology  is  emerging  that  developers  of  design  tools,  and 
subsequently  designers,  can  use  to  increase  design  productivity  enough  to 
offset  the  considerable  increase  in  the  complexity  of  the  design  problem 
associated  with  up-front  consideration  of  downstream  producibility  and 
supportability  concerns. 
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2 .  Object-Centered  Implementation  of  an  ULCE  Environment 


The  Design-in-Process  and  Design  Decision  Process  elements  of  the  Reference  A-l 
architecture  for  an  ULCE  environment  can  be  implemented  using  an  object-centered 
programming  approach.  The  advantages  of  such  an  implementation  are  described  in  the 
following  paragraphs. 

The  information  content  of  the  functional  decomposition  has  a  relatively  simple 
structure,  which  can  be  implemented  using  conventional  programming  methods,  such  as 
relational  database  management  systems.  However,  a  description  of  the  functional 
breakdown  using  system  function  objects  would  simplify  the  development  of  user 
interfaces.  Good  user  interfaces  are  essential  to  make  the  coupled,  leveled  structure  of  the 
functional  decomposition  accessible  to  members  of  the  product  development  team. 

Object-centered  techniques  would  have  considerable  value  for  implementing  the 
system  description  component  of  the  Design-in-Progress.  Here,  system  element  objects 
could  be  defined,  with  local  variables  and  methods  providing  access  to  geometry,  material 
and  process  specifications,  technical  orders,  and  other  views  of  the  objects.  Manufacturing 
processes  and  support  concepts  are  also  represented  in  the  Design  in  Progress.  This 
capability  then  provides  the  product  development  team  (including  producibility  and 
supportability  engineers)  with  an  environment  to  define  alternative  manufacturing  plans  and 
maintenance  procedures  and  to  evaluate  them  along  with  system  alternatives. 

A  multilevel  approach  to  defining  and  instantiating  system  element  objects  would 
provide  the  design  team  with  the  capability  to  partially  instantiate  designs  for  evaluation  and 
comparison.  The  status  of  instances  of  design  alternatives  could  be  managed  using  local 
state  variables.  By  virtually  eliminating  the  cost  of  generating  design  detail,  instantiation 
can  make  system-level  trade  studies,  and  the  capability  to  adapt  the  product  or  process  to 
respond  to  them,  a  reality  throughout  the  product  life  cycle. 

The  representation  of  engineering  theories  and  models  using  object-centered 
programming  techniques  also  offers  significant  benefits.  The  capability  of  objects  to 
manage  the  execution  of  computer  programs  written  in  FORTRAN  and  other  languages 
would  be  quite  valuable.  Explicit  representation  (as  objects)  of  alternative  theories  and 
models  describing  the  accomplishment  of  the  same  group  of  system  functions  at  different 
levels  of  system  description  definition  precisely  represents  the  idea  of  levels  of 
approximation.  This  information  is  extremely  useful  in  managing  design  state  and 
assessing  levels  of  risk  throughout  the  design  process. 
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Finally,  design  decision  objects  could  be  defined  in  the  Design  Decision  Process 
element  of  the  ULCE  architecture.  The  meta-design  process  would  result  in  the 
instantiation  of  design  decisions.  During  the  Make  Design  Decisions  step,  the  design 
decision  objects  provide  user  interfaces  and  manage  the  execution  of  procedures  for 
decision  support. 

D.  CONSTRAINT  PROPAGATION  AND  META-DESIGN 
1 .  Constraint  Propagation 

A  constraint  is  a  restriction  on  the  values  that  may  be  taken  on  by  a  design  attribute. 
(This  usage  is  consistent  with  the  concept  of  equality  and  inequality  constraints  in  design 
optimization.)  Equality  and  inequality  constraints  are  here  referred  to  collectively  as 
feasibility  constraints.  Equality  constraints  may  bind  a  design  attribute  to  a  specified 
constant,  or  they  may  bind  several  design  attributes  in  an  equation.  Inequalities  may  also 
represent  a  relationship  among  several  design  attributes,  or  they  may  be  restrictions  on  the 
values  allowed  for  a  single  design  attribute  (in  design  optimization  terminology  .variable 
bounds). 

Values  that  may  be  taken  on  an  attribute  may  also  be  restricted  by  a  competitive 
strategy  or  goal.  Thus,  the  statement  that  a  particular  attribute  is  to  be  minimized, 
maximized,  or  close  to  a  target  value  effectively  constrains  that  attribute.  The  goal  of 
balanced  design  also  acts  as  a  constraint  in  this  sense,  since  balance  is  a  form  of  optimality 
(Pareto-optimality).  Restrictions  of  this  type  are  also  considered  here  to  be  constraints 
(optimality  constraints). 

An  extension  of  existing  methods  for  propagating  equality  constraints  to  handle 
optimality  and  feasibility  constraints  can  be  based  on  the  methods  used  in  this  paper.  To 
illustrate  the  idea,  we  first  consider  propagation  of  equality  constraints.  (Propagation  of 
feasibility  constraints,  of  a  single  optimality  constraint,  and  of  multiple  optimality 
constraints  are  considered  in  Appendices  B,  C,  and  D  of  this  paper.) 

Constraint  propagation  is  a  technique  for  structuring  computer  programs  to  represent 
constraints  directly  in  software.  The  distinction  between  the  definition  of  aspect  ratio, 
aspect_ratio  =  span2/area 

and  an  instruction  in  a  conventional  computer  program 


aspect_ratio  =  spanA2/area 


set  aspect_ratio  to  span/v2/area 

is  essential  for  the  concept.  The  instruction  sets  the  value  of  "aspect_ratio"  to  the  square  of 
the  value  bound  to  the  variable  name  "span,"  divided  bv  the  value  bound  to  the  variable 
name  "area."  The  instruction  is  meaningless  unless  it  can  be  executed.  The  definition  of 
aspect  ratio,  on  the  other  hand,  can  be  interpreted  as  a  declaration  that  aspect  ratio  is  equal 
to  the  square  of  the  span  divided  by  the  area.  This  declaration  is  independent  of  the  values 
for  span,  area,  and  aspect  ratio.  More  important,  the  definition  of  aspect  ratio  is  a  statement 
that,  given  values  for  any  two  of  the  three  variables,  we  can  solve  for  the  other  (we  may 
have  to  specify  which  root  to  take). 

In  contrast,  the  instruction  has  meaning  (it  can  be  executed)  only  if  values  have 
already  been  bound  to  the  span  and  the  area  variable  names.  Thus,  the  instruction  implies  a 
sequence  of  determining  the  design  attributes  .  The  definition  does  not.  The  programming 
style  in  which  constraint  definitions  are  represented  explicitly  in  the  software  is  often  called 
declarative.  The  conventional  approach,  working  directly  with  instructions,  is  described  as 
imperative.  This  distinction  extends  beyond  programming  style,  and  can  be  used  to 
characterize  declarative  and  imperative  types  of  knowledge,  as  is  done  in  Ref.  A-4: 

"The  contrast  between  function  and  procedure  is  a  reflection  of  the  general 
distinction  between  describing  properties  of  things  and  describing  how  to 
do  things,  or,  as  it  is  sometimes  referred  to,  the  distinction  between 
declarative  knowledge  and  imperative  knowledge." 

"...  an  important  current  area  in  programming-language  design  is  the 
exploration  of  so-called  very  high-level  languages,  in  which  one  actually 
programs  in  terms  of  declarative  statements.  The  idea  is  to  make 
interpreters  sophisticated  enough  so  that,  given  "what  is"  knowledge 
specified  by  the  programmer,  they  can  generate  "how  to"  knowledge 
automatically.  This  cannot  be  done  in  general,  but  there  are  important  areas 
where  progress  has  been  made." 

The  sequence  of  design  decisions  is  to  be  identified  through  meta-design  in  the  life 
cycle  engineering  architecture.  Conventional  computer  programming,  using  instructions  to 
represent  design  concepts,  severely  limits  this  flexibility.  Thus,  to  use  meta-design  to 
advantage,  we  should  use  declarative  programming  to  represent  system  life  cycle  concepts. 

When  the  Make  Design  Decisions  step  of  the  Figure  A-2  life  cycle  engineering 
process  architecture  is  executed,  we  will  need  a  procedure  for  translating  the  flexible 
declarative  description  of  the  design  concept  into  a  set  of  instructions  for  binding  the  design 


attributes  to  specific  choice^.  How  this  can  be  done  using  an  object-cente/ed 
implementation  of  constraint  propagation  is  detailed  in  the  following  paragraphs. 

In  an  object-centered  system  for  constraint  propagation,  the  constraints  themselves 
are  represented  as  objects.  The  defining  equation  of  the  constraint  is  an  instance  variable. 
This  allows  different  instances  of  the  constraint  object  to  represent  different  constraints.  In 
one  approach  to  constraint  propagation,  the  fixed  point  method  of  Elias  [Ref.  A-5],  the 
constraint  objects  have  a  method  for  using  the  values  bound  to  all  but  one  of  the  variables 
to  solve  for  the  remaining  one. 

Instances  of  the  constraint  objects  must  also  manage  information  about  the  defining 
equations.  As  an  example,  it  is  quite  important  to  Know  that  aspect  ratio  cannot  be 
determined  from  the  span  and  the  area  when  the  area  is  zero,  or  that  the  determination  of 
span  from  aspect  ratio  and  area  is  not  unique  (both  b  and  -b  are  solutions). 

The  variables  appearing  in  the  defining  equations  represented  by  the  constraint 
instances  are  also  implemented  as  objects.  The  purpose  of  the  defining  equation  variable 
objects  is  to  manage  the  state  of  the  design.  The  state  of  an  instance  of  a  defining  equation 
variable  object  is  represented  by  an  instance  variable  that  is  given  a  value  "user-specified," 
"guess,"  or  "computed."  Figure  A-7  depicts  constraint  and  variable  objects  implementing 
design  attributes  and  relationships  for  the  aircraft  aircraft  sizing  problem  shown  in  Figure 
A-6. 


Figure  A-7.  Constraint  and  Variable  Objects 

A  computer  program  employing  constraint  propagation  is  used  in  the  following  way. 
The  user  specifies  fixed  values  for  some  of  the  design  attributes.  The  program  then  uses 
information  about  the  relationships  (whether  a  defining  equation  can  be  used  to  solve  for 
the  set  of  variables  that  has  been  specified)  to  develop  a  computational  agenda  [Ref.  A-5], 
The  computational  agenda  is  a  sequence  of  steps  (a  design  path)  for  using  the  fixed  values 
and  the  available  relationships  to  solve  for  the  unspecified  values.  The  computational 
agenda  can  then  be  interpreted  as  instructions  and  executed  as  a  computer  program. 

All  combinations  of  user-specified  initial  values  can  be  propagated.  Kolb  [Ref.  A- 11] 
presents  a  detailed  investigation  into  the  complications  that  may  result  when  a  relationship 
with  a  multivalued  inverse  is  reversed  in  the  design  path. 

The  transition  of  defining  equation  variable  states  from  guess  to  computed  seems  to 
propagate  across  the  G-digraph  as  the  computational  agenda  is  executed,  hence  the  term 
constraint  propagation  . 
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Elias  [Ref.  A-5]  recognized  the  close  analogy  between  the  choice  of  which  attributes 
to  bind  to  fixed  values,  development  of  a  computational  agenda,  and  solution  of  the 
constraint  propagation  network  on  one  hand;  and  the  requirements  definition,  meta-design, 
and  sizing/synthesis  elements  of  the  aircraft  design  process  on  the  other.  In  Elias'  view, 
the  computational  agenda  is  the  result  of  the  meta-design  step. 

2 .  Relating  Design  Methodologies  to  the  Propagation  of  Optimality  and 
Feasibility  Constraints 

The  constraint  propagation  idea  is  closely  related  to  meta-design  in  a  life  cycle 
engineering  environment  Advanced  computing  technologies  will  be  needed  to  implement  a 
life  cycle  engineering  architecture  in  a  competitive  economic  climate.  Constraint 
propagation  provides  the  means  for  the  system  development  team  to  execute  a  design 
process  represented  in  an  advanced  computing  environment 

Inherent  in  the  life  cycle  engineering  concept  is  the  idea  of  balanced  design  . 
Balancing  a  design  against  multiple  criteria  means  that  an  improvement  in  any  one  criterion 
can  only  be  obtained  at  the  expense  of  worsening  at  least  one  of  the  other  criteria.  This 
concept  is  called  Pareto-optimality  . 

In  turn,  Pareto-optimality  is  a  parameterization  of  "ordinary"  optimality  by  weighting 
factors  representing  the  relative  importance  of  the  multiple  criteria.  Thus,  to  address  life 
cycle  engineering  in  an  advanced  computing  environment  for  design,  we  need  to 
understand  how  to  propagate  optimality  and  feasibility  constraints. 

We  construct  a  computational  agenda  for  constraint  propagation  from  the  decision 
sequence  identified  using  methods  such  as  those  of  Chapter  IV  of  this  paper.  Such  a 
design  process  can  then  be  executed  by  applying  requirements  to  specify  initial  values  for 
design  attributes. 

Decision  elements  are  identified  as  groups  of  attributes  of  the  design-in-progress  that 
are  to  be  determined  together.  One  such  grouping  is  shown  in  Figure  A-8. 
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Figure  A-8.  Identification  of  Decision  Elements 

Making  design  decisions  results  in  the  determination  of  values  for  the  design 
attributes.  Since  the  attributes  are  related,  the  decision  elements  are  also  related.  Thus,  the 
complex  G-digraph  structure  shown  in  Figure  A-6  induces  an  ordinary  directed  graph 
structure  on  the  decision  elements  in  Figure  A-8,  as  shown  in  Figure  A-9.  The  edges  on 
the  Figure  A-9  directed  graph  indicate,  for  example,  that  determining  take-off  gross  weight 
by  making  decision  D3  will  have  a  direct  effect  on  decision  D2.  This  reflects  the  fact  that 
there  are  two  directed  edges  from  D3  to  D2  in  the  G-digraph  shown  in  Figure  A-6.  The 
directed  edge  connecting  decision  D4  to  decision  D3  indicates  that  D3  will  be  affected  by 
the  values  for  landing  weight  and  mission  fuel  selected  in  decision  D4. 
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Figure  A-9.  Relationships  Among  Decision  Elements 

As  illustrated  in  Figure  A- 10,  sequencing  of  the  decision  elements  is  accomplished 
by  eliminating  some  of  the  edges  from  the  directed  graph  of  Figure  A-9. 


Figure  A-10.  Decision  Sequence 

Given  a  decision  sequence,  a  computational  agenda  can  be  constructed  as  shown  in 
Figure  A-ll. 
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Figure  A-11.  Computational  Agenda  for  Constraint  Propagation. 


To  build  a  computational  agenda,  declarative  information  about  the  design  concept  is 
interpreted  as  a  procedure  for  setting  values  for  the  design  attributes.  The  sequence  of 
imperative  steps  in  the  procedure  is  based  on  the  decision  sequence  in  Figure  A- 10.  The 
initial  selections  of  values  for  design  attributes  are  made  in  decisions  Dl,  D3,  D9,  DIO,  and 
D12.  For  example,take-off  gross  weight  is  given  a  value  in  decision  D3.  Once  take-off 
gross  weight  has  been  determined,  we  can  apply  the  constraint 

structural  weight  fraction  =  1.222  (take-off  gross  weight )  *-1618 

to  determine  a  value  for  the  structural  weight  fraction  .  Using  the  take-off  gross  weight 
and  structural  weight  fraction  ,  the  structural  weight  can  be  found  by  inverting  the 
constraint 

structural  weight  fraction  =  structural  weight  /take-off  gross  weight , 
as  indicated  by  the  arrows  in  Figure  A- 1 1 . 

Continuing  along  these  lines,  the  constraints  imposed  by  selecting  values  for  the 
trapped  fuel  and  oil  ,  fixed  equipment,  reserve  fuel  weight  ,  payload  weight  ,  crew 
weight ,  and  mission  range  are  propagated  to  determine  values  for  all  of  the  other  design 
attributes.  Since  the  computational  agenda  is  a  procedure  for  determining  these  values,  it 
can  be  interpreted  and  executed  as  a  computer  program. 

The  relationship  between  constraint  propagation  and  requirements  flowdown  can  now 
be  clarified.  Design  attributes  such  as  mission  range  and  reserve  fuel  are  typically  set  by 
requirements  (such  as  those  specified  in  the  RFP,  MIL-Specs,  or  FARs).  The  flowdown 
of  these  requirements  to  specification  of  system  attributes  is  clearly  traced  by  the 
computational  agenda.  A  similar  process  takes  place  as  the  system  development  team 
makes  decisions  that  place  constraints  on  the  choices  available  to  subsystem  development 
teams. 

A  computational  agenda  can  be  constructed  from  any  decision  sequence.  A  typical 
design  goal  in  conceptual  sizing  is  to  minimize  take-off  gross  weight.  The  decision 
sequence  in  Figure  A- 10  is  neither  optimizing  or  feasible.  Since  the  take-off  gross  weight 
is  set  initially,  a  single  pass  through  the  decision  sequence  cannot  make  any  progress 
toward  an  optimal  value.  The  decision  sequence  is  not  feasible,  either.  Tracing  the 
sequence  of  computations  indicated  in  Figure  A-l  1  will  show  that  the  mission  fuel  fraction 
and  the  landing  weight  appear  to  be  over-determined.  In  fact,  the  intent  of  decision  D4  is 
to  compare  the  two  values  for  the  mission  fuel  fraction  to  support  the  selection  of  a  power- 
or  thrust-generating  propulsion  subsystem.  Thus,  the  mission  fuel  fraction  is  not  really 
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overdetermined.  The  landing  weight  is  overdetermined,  however.  All  of  the  constraints  in 
which  landing  weight  appears  must  be  satisfied  identically.  An  example  of  a  balanced 
design  methodology  for  an  aircraft  sizing  problem  is  presented  in  Appendix  D. 

In  Appendix  B,  we  present  and  analyze  an  effective  procedure  for  structuring  a 
decision  sequence.  We  prove  that  this  procedure  ensures  that  execution  of  the 
computational  agenda  will  make  progress  toward  optimization  of  a  single  design  objective 
function,  or  balance  of  multiple  objective  functions,  while  maintaining  a  feasible  design. 
Since  constraint  propagation  is  effected  by  execution  of  a  computational  agenda,  this 
procedure  can  be  usefully  considered  to  be  a  method  for  the  propagation  of  feasibility 
constraints,  and  a  single  optimality  constraint,  or  balanced  design  constraints. 
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PROGRESS  TOWARD  A  THEORY  OF  OPTIMAL 
DECISION  SEQUENCES 


This  appendix  provides  the  technical  justification  for  the  application  of  optimization 
theory  to  evaluate  design  methodologies.  Here,  we  prove  the  following  results: 

•  Global  convergence  of  a  design  methodology  follows  from  global  convergence 
of  the  methods  used  to  solve  the  subproblems  (decision  elements).  Here 
global  convergence  means  that  the  algorithm  converges  from  any  initial  design 
point  [Ref.  B-l], 

•  The  convergence  test  dfldxi  =  0  ( dfldxi  is  an  optimal  sensitivity  derivative), 
for  all  i ,  is  satisfied  at,  and  only  at,  a  Kuhn-Tucker-Karush  point. 

•  dF  I  dp  (co)  =  £  <0i  dfi  I  dp 

where  F  =  £  coj/j- .  The  last  equality  expresses  the  form  of  the  relationship  between  the 
optimal  sensitivity  derivative  of  the  objective  function  for  a  Pareto-optimization  problem 
and  the  optimal  sensitivity  derivatives  of  the  multiple  objectives.  We  establish  that  this 
equation  also  describes  the  effect  on  the  Pareto-optimal  sensitivity  derivative  dF  /dp  of 
changes  in  the  relative  prioritizations  coi. 

These  results  provide  the  justification  for  the  technique  of  using  approximations  to 
the  objective  functions  of  subproblems  as  the  optimality  conditions  for  a  Pareto- 
optimization  problem.  This  technique  forms  the  basis  for  methodology  F  of  Chapter  IV 
and  for  the  solution  of  a  Pareto-optimal  aircraft  sizing  problem  in  Appendix  D. 

The  precise  relationship  of  design  methodologies  structured  using  the  procedure 
described  in  this  paper  to  other  decomposition  methods  of  design  optimization  has  not  yet 
been  established.  The  point  of  view  of  the  method  of  this  paper,  the  method  itself,  and  a 
fortiori ,  the  convergence  results  of  this  appendix,  are  essentially  new.  However,  the 
method  of  this  paper  is  closely  related  to  the  techniques  described  in  reference  B-2  and 
work  cited  there.  The  method  differs  from  coordinate  descent  methods,  such  as  that  of 
Gauss-Southwell  (discussed  in  reference  B-l),  in  that  the  optimization  subproblems  may 
be  constrained  and  may  include  several  design  variables. 


A.  AN  OPTIMIZING  PROCEDURE  FOR  SEQUENCING  DESIGN 
DECISIONS 

Planning  a  design  decision  making  process  requires  a  procedure  that  can  be  used  to 
identify  and  sequence  design  decision  elements.  In  the  context  of  optimization  theory,  an 
effective  procedure  for  design  decision  making  is  a  technique  for  iterative  solution  of  an 
optimization  problem,  P.  This  problem  can  be  stated  as  follows: 

minimize  /  (x) 

subject  to  g(x)  <  0 

h(x)  =  0 

X  lower  -  *  -  x  upper 

where /  is  a  scalar-valued  function  of  a  vector  variable 

x  =  (xi,  X2, - xn  ). 

/  is  referred  to  as  the  objective  function  .  The  r,  's  are  the  design  variables,  and  g 
and  h  are  vector-valued  functions  of  x.  The  components  of  g  are  the  inequality  constraints 

gk(xi,X2,  .  . .  ,xn)  £0  k  =  l,...,nj 

and  the  components  of  h  are  the  equality  constraints 

hi(xi,x 2,  =  0  1=1,  ...,ne 

xiower  and  xupper  are  vectors  of  upper  and  lower  bounds  for  x.  A  starting  value 
for  the  design  variable  vector,  x°,  satisfying  the  upper  and  lower  bound  inequalities,  is 
given. 

P  is  decomposed  into  subproblems,  referred  to  as  decision  elements.  In  this 
decomposition,  each  decision  element  Dj  is  associated  with  a  nonempty  subset  of  the  xi 's. 
Each  xi  is  assigned  to  a  unique  Dj.  The  xt 's  assigned  to  Dj  are  called  local  design 
variables  for  Dj  . 

Each  decision  element  Dj  is  also  associated  with  an  optimization  subproblem  or  a 
feasibility  subproblem.  These  subproblems  include  all  of  the  constraints  gk  and  h{  in 
which  any  local  design  variable  for  Dj  is  explicit.  If  a  local  design  variable  x,  is  explicit  in 
the  objective  function  /,  then  the  subproblem  is  formulated  as  an  optimization  subproblem 
with /as  objective  function.  If  not,  Dj  is  a  feasibility  subproblem.  Design  variables  xi 
not  assigned  to  Dj  may  be  explicit  in  the  constraints  or  the  objective  function  of  the 
optimization/feasibility  subproblem  associated  with  Dj .  These  design  variables  are 


parameters  for  Dj .  Each  design  variable  of  the  problem  P  may  be  a  parameter  for  a 
number  of  decision  elements. 

Two  decision  elements  may  be  combined  by  forming  the  union  of  their  local 
variable  sets  and  formulating  a  new  optimization  or  feasibility  problem  in  the  obvious  way. 

We  now  drop  the  distinction  between  the  decision  element  Dj  and  its  associated 
optimization  or  feasibility  subproblem. 

The  values  of  all  parameters  are  fixed  during  the  solution  of  D j.  In  a  sequential 
solution  process,  the  values  for  the  local  design  variables  determined  by  the  solution  of  Dj 
are  passed  as  parameters  to  subsequent  decision  elements. 

The  term  solution  sequence  is  used  here  to  mean  a  directed  graph  with  the  decision 
elements  as  nodes.  The  edges  are  labelled  with  a  vector  of  bindings  for  the  parameters. 
The  directed  graph  represents  the  order  in  which  the  decision  elements  are  to  be  executed  or 
solved.  This  definition  allows  us  to  consider  multiple  predecessors  and  successors,  as  well 
as  concurrent  solution  of  decision  elements. 

Convergence  of  die  design  decision  plan  to  an  optimal  or  balanced  design  is 
ensured  by  placing  restrictions  on  the  allowable  sequences  of  decision  elements.  It  may  be 
necessary  to  combine  decision  elements  to  construct  such  a  solution  sequence.  If  decision 
elements  may  be  combined,  the  set  S  of  optimal  and  feasible  solution  sequences  is  not 
empty  if  there  is  a  procedure  for  finding  an  optimal  feasible  solution  for  P  .  The  solution 
sequence  {Z3  }  is  an  element  of  S,  since  P  can  be  recovered  by  combining  all  of  the 
decision  elements. 

1 .  Feasible  and  Optimal  Decision  Sequences 

A  design  decision  D/  can  be  made  before  another  design  decision  D2  if  the  values 
chosen  for  the  design  attributes  in  D\  do  not  make  D2  infeasible.  For  example,  say  xj  is  a 
design  variable  to  be  determined  by  Dj  and  X2  a  design  variable  to  be  determined  in 
decision  £>2 .  Say  xj  and  X2  are  coupled  by  an  inequality  constraint  g  : 

g(xiJ2,  •  •  • )  ^  0  . 

In  sequencing  D\  and  D2  we  have  three  alternatives: 

1)  make  decision  Dj  before  D2;  xi  will  then  be  fixed  by  Di  and  will  be  a 
parameter  for  decision  D2  . 

2)  Make  decision  D2  before  D/;  X2  will  be  a  parameter  in  Dj. 

3)  Combine/)/  andZ>2  into  a  single  decision  element. 


Consider  now  the  case  where  D;  is  sequenced  before  £>2-  Solution  of  Dj  will  result 
in  a  change  Ax/  from  the  initial  value  forx/.  The  effect  of  this  change  on  the  inequality 
constraint  g  can  be  assessed  with  a  first-order  approximation: 

Ag~  (dgldxj)  Axj 

Thus  if  (dgldxi)  and  Ax/  are  opposite  in  sign,  Ag  will  be  negative  and  g  will 
be  less  critical  in  making  decision  D2  (in  comparison  with  the  initial  design).  If  ( dgldxi ) 
and  Axj  have  the  same  sign,  g  will  become  more  critical  for  D2  if  we  make  decision  D / 
first. 

Feasible  sequences  for  the  design  decisions  can  be  determined  using  the  directions 
of  proposed  changes  in  the  design  variables  in  each  decision  and  the  signs  of  the  partial 
derivatives  of  inequality  constraints  coupling  two  or  more  decisions  together.  The  criteria 
are 

F-l  If  D]  does  not  make  (any  of)  the  constraints  of  D 2  more  critical,  then  Dj 
can  be  sequenced  before  D2. 

F-2  If  D2  does  not  make  (any  of)  the  constraints  of  Dj  more  critical,  then  D2 
can  be  sequenced  before  D  / . 

If  Dj  makes  the  constraints  of  D2  more  critical,  and  D2  makes  the  constraints  of 
D 1  more  critical,  then  it  may  be  necessary  to  combine  D /  and  D2  into  a  single  decision 
element. 

If  both  F-l  and  F-2  are  met,  Dj  and  O2  can  be  made  concurrently. 

Many  possible  decision  sequences  may  meet  these  criteria.  In  an  extremely  tightly 
coupled  problem,  all  of  the  initial  design  decisions  may  be  combined  into  a  single  design 
decision  by  this  procedure.  All  of  the  decision  sequences  meeting  criteria  F-l  and  F-2  will 
lead  to  feasible  designs.  We  will  next  consider  additional  restrictions  on  the  possible 
decision  sequences,  leading  to  an  optimal,  and  subsequently,  a  Pareto-optimal  or  balanced 
design. 

Determination  of  a  sequence  of  design  decisions  leading  to  an  optimal  design 
requires  an  initial  suboptimization  pass  through  each  of  the  decision  elements.  In  this 
suboptimization  pass,  each  of  the  decisions  in  which  one  of  the  objective  functions  for  the 
design  appears  explicitly  as  a  function  of  the  local  decision  variables  is  solved  in  isolation. 
The  results  of  the  suboptimization  pass  are  then  analyzed  using  sensitivity  of  optimal 
solutions  to  problem  parameters.  That  analysis  is  used  to  establish  whether  an  iteration  of 
the  decision-making  procedure  will  progress  toward  an  optimal  design. 


In  constructing  a  decision  sequence  leading  to  an  optimal  design,  we  again  have  the 
three  alternatives:  place  D/  before  D2  in  the  decision-making  sequence,  place  D2  before 
D]  ,  or  combine  them.  Let  f(x\X2  ,  ■  ■  ■ )  be  an  objective  function  to  be  minimized  in 
both  Dj  and  D2  ■  If  Dj  is  made  before  D2,  then  xj  appears  in  D2  as  a  parameter.  The 
sensitivity  of  the  optimal  solution  to  D  2  to  the  parameter  X]  is  dfldxi,  We  know  the 
directions  of  proposed  changes  in  the  design  variables  (from  the  suboptimization  pass),  so 
we  can  determine 

Af  ~  (dfldxi)  Ax  1 

Thus,  if  dfldxi  and  Ax]  are  opposite  in  sign,  Af  will  be  negative.  Then  if  D;  is 
made  before  D2,f  will  not  increase  during  the  decision  subsequence  { Dj ,  D2  }.  Any 
decision  subsequence  in  which/  will  not  increase  can  form  part  of  an  optimizing  decision 
sequence.  Optimizing  decision  sequences  are  built  up  from  such  subsequences,  with  one 
additional  criterion:  decision  elements  with  dfldxi  =  0  must  be  placed  after  decision 
elements  with  dfldxi  *  0.  The  need  for  this  criterion  will  emerge  from  consideration  of 
convergence  questions. 

We  now  establish  global  convergence  of  an  effective  procedure  for  solving  an 
optimization  problem  using  an  optimizing  sequence  of  design  decisions. 

2.  An  Effective  Procedure  for  Optimization  through  the  Sequence  of  Design 
Decisions 

Step  0.  Initialization.  Choose  an  initial  design  within  the  variable  bounds  and 
make  an  initial  choice  of  decision  elements. 

Step  1.  Evaluate  each  decision  element  to  determine  an  optimum  solution  for 
that  decision  element  (in  isolation). 

Step  2.  Identify  possible  feasible  decision  sequences.  If  feasibility  requires 
combination  of  decision  elements,  iterate  with  Step  1 . 

Step  3.  Identify  possible  optimal  decision  sequences.  Check  convergence.  If 
solution  is  converged,  stop.  If  optimality  requires  combination  of 
decision  elements,  iterate  with  Steps  1  and  2. 

Convergence  criterion:  Both 

(i)  design  variables  did  not  change  during  last  solution  pass  and 

(ii)  all  optimal  sensitivities  are  zero  ( dfldxi  =  0  for  all  parameters  xi )  must  be 
satisfied. 

Step  4.  Select  a  decision-making  sequence  that  is  both  feasible  and  optimal.  If 
D,-  is  sequenced  before  Dj,  the  number  of  parameters  passed  from  D/  to 


Dj  must  equal  or  exceed  the  number  of  independent  active  constraints 
common  to  both  decision  elements. 

Step  5.  Find  an  optimal  solution  for  each  decision  element  in  sequence.  Update 
the  values  of  all  design  variables  and  iterate  from  Step  2. 

3.  Proof  of  Convergence 

We  would  like  the  procedure  to  converge  to  an  optimal  solution  from  any  initial 
design  within  the  variable  bounds.  This  property  is  known  as  global  convergence  in 
optimization  theory  [Ref  B-l].  (Global  convergence  is  not  the  same  as  convergence  to  a 
global  optimum.) 

In  the  theory  of  convergence,  an  algorithm  is  a  mapping,  often  considered  to  be  a 
point- to- set  mapping,  although  that  level  of  generality  is  not  needed  to  analyze  the 
convergence  of  the  procedure  presented  here.  An  algorithm  corresponding  to  a  feasible, 
optimizing  decision  sequence  can  be  thought  of  as  a  vector-valued  function.  A,  of  a  vector 
variable  x.  x  is  the  vector  of  design  variables  (xj,  X2, . .  . )  .  A  particular  value  of  x, 
corresponding  to  choices  for  each  of  the  design  variables,  is  called  a  design.  A  maps  the 
design  before  an  iteration  of  Steps  2  through  5  (above),  that  is,  x;,  to  a  new  design 
determined  by  the  algorithm,  Xj+i  =  A(xj).  A  sequence  of  points  {xj)  obtained  by 
iteration  of  the  algorithm  in  this  way  is  said  to  be  generated  by  the  algorithm  A. 

Global  convergence  for  the  algorithm  A  follows  from  the  following  conditions 
[Ref.  B-l]: 

1 .  Sequences  generated  by  A  remain  in  a  compact  (closed,  bounded)  set. 

2 .  The  mapping  defined  by  A  is  continuous. 

3.  A  descent  function  can  be  defined  for  A. 

Condition  (1)  follows  directly  from  global  convergence  of  the  algorithms  used  to 
optimize  individual  decision  elements. 

Condition  (2)  will  follow  from  continuity  of  the  objective  and  constraint  functions  if 
the  optimal  sensitivity  derivatives  are  continuous .  The  optimal  sensitivity  derivatives  may 
have  discontinuities  at  values  of  the  parameter  corresponding  to  changes  in  the  active 
constraint  set.  These  discontinuities  can  be  removed  by  replacing  the  optimal  sensitivity 
derivative  with  a  continuous  approximation.  A  suitable  procedure  (a  closed  algorithm 
choosing  a  feasible,  optimal  decision  sequence  must  also  be  specified. 

Condition  (3)  requires  us  to  find  a  descent  function  for  A.  A  descent  function 
measures  the  progress  of  the  algorithm  toward  a  solution.  The  descent  function  must 
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decrease  with  each  iteration  until  the  solution  set  is  reached.  A  penalty  function,  P,  formed 
from  the  problem  objective  function  and  constraints,  will  be  a  descent  function  for  A 
provided  that  P  is  a  descent  function  for  the  globally  convergent  algorithms  used  to 
optimize  each  decision  element  and  decision  elements  with  df/dxi  =  0  are  be  placed  after 
decision  elements  with  dfldxi  <  0.  Then  the  first  decision  elements  in  the  sequence  will 
decrease  P  unless  all  of  the  df/dxi  are  0.  Subsequent  decision  elements  will  not  increase 
P.  Then  P  will  decrease  with  each  iteration  until  a  local  optimum  for  the  whole  problem  is 
reached. 

Thus  the  solution  set  for  the  algorithm  is  defined  by  the  condition  that  all  df/dxi  =  0 
.  We  must  now  show  that  this  solution  set  is  the  set  of  Kuhn-Tucker-Karush  points. 

A  Kuhn-Tucker-Karush  point  is  a  point  satisfying  the  Kuhn-Tucker-Karush 
optimality  conditions: 

1.  Feasibility 

g(x)  <  0 
h(x)  =  0 

2.  Active  constraints: 

h  >  0  and  A*g*(x)  =0  k  =  1, . . .,  nj 

3.  Extremum  of  the  Lagrangian  over  the  primal  space: 

df/dxi  +  £  Xkdg/Jdxi  =  0  for  each  design  variable  i. 

Convergence  of  the  procedure  for  optimization  through  decision  sequencing  to  a 
Kuhn-Tucker-Karush  point  follows  from 

Proposition  1:  Let  x*  be  a  point  generated  by  the  decision  sequence.  If  all  df/dxi 
are  0  at  x*,  then  x*  is  a  Kuhn-Tucker-Karush  point. 

Proof:  Satisfaction  of  the  first  of  the  Kuhn-Tucker-Karush  condition  follows  from 
the  optimization  of  the  individual  decision  elements  in  Step  5.  To  establish  that  the  second 
and  third  optimality  conditions  are  satisfied,  we  must  prove  that  values  of  the  Lagrange 
multipliers  corresponding  to  a  constraint  gk  are  well  defined,  even  though  they  may  be 
determined  by  the  solution  to  more  than  one  subproblem.  We  establish  this  result  by 
analyzing  the  convergence  criterion,  which  requires 

dfldxi  =  dfldxi  +  £  Xkdgk/dxi  =  0, 

where  Xi  is  a  parameter.  This  equation  is  similar  in  form  to  the  optimality  condition 


cfldxi  +  X  Xkdgk!dxi  =  0, 

except  that  X[  appears  in  the  optimality  condition  as  a  design  variable.  Also,  Xk  does  not 
have  the  same  meaning  in  both  equations.  We  need  to  distinguish  between  the  optimal 
values  of  the  Lagrange  multipliers  Xk  for  the  entire  problem  and  those  for  the  local  problem 
on  which  df/dxi  is  based.  Denote  a  Xk  for  the  entire  problem  by  Xk*.  We  will  need  to 
distinguish  between  locally  determined  Xk  's  and  df/dxi  's  defined  by  different  decision 
elements,  so  index  these  Xk  1  and  df  tydx; . 

Let  Di  contain  a  design  variable  xp  which  appears  explicitly  in  the  constraint  gk. 
Define  Xk  to  be  the  value  Xk  1  determined  from  the  optimal  solution  to  Dj.  We  show  that 
Xk  1  defined  in  this  way  is  unique,  that  is,  the  value  of  A*  does  not  depend  on  the  choice  of 
a  decision  element  containing  gk.  We  then  show  that  Xk  *  =  Xk  exists  satisfying  the  Kuhn- 
Tucker-Karush  condition, 

df/dxi  =  df/dxi  +  X  Xk  dgkldxi  =  0 
for  any  i.  This  will  establish  the  result. 

Uniqueness  of  the  Xk  's  follows  from  the  requirement  that  the  number  of 
parameters  passed  from  decision  element  Dj  to  decision  element  £>2  is  greater  than  or  equal 
to  the  number  of  independent  active  constraints,  which  are  in  common  to  both  decision 
elements.  Let  p\,  i  -  1 be  parameters  passed  from  D]  to  £>2-  Then  the  convergence 
criterion  specifies  that  the  optimal  sensitivity  derivatives  dft/dpj  =  0,  i  =1  From  the 
definition  of  the  optimal  sensitivity  derivative  we  have 

dfildpi  =  dfldpi  +  X k  in  d2  h2dgk/dpi  =  0  i  =  l,...,n. 

The  pi  are  local  design  variables  in  Dj.  Thus  from  the  optimality  conditions  for 
Dj  we  have 

dfldpt  +  X  kin  DjXk1  dggldpi  =  0  i  =  1 . 

Clearly,  if  gk  does  not  appear  in  £>;  ,  then  dgkldpi  =  0,  since  pi  is  a  design  variable 
in  £>/  and  Dj  contains  all  of  the  constraints  in  which  its  design  variables  appear  explicitly. 
Also,  if  gk  does  not  appear  in  £>2,  we  may  arbitrarily  set  Xk2  =  Xkl  without  affecting  the 
validity  of  the  result.  Making  these  changes  and  combining  the  two  linear  systems  of  n 
equations,  we  have 

E k  in  Dl  ( h1  *  h2)dgk/dpi  =  0  i  =  1 ,...,« 

Since  the  constraints  are  independent,  we  have  n  equations  in  the  m  unknowns 
X k 1  •  Xk2.  By  assumption,  there  are  at  least  as  many  parameters,  n  ,  as  there  are 


independent  constraints,  m  .  Thus  the  linear  system  has  either  no  solutions 
(overdetermined)  or  has  a  unique  solution.  The  linear  system  has  a  solution  if  the  decision 
element  D i  has  a  feasible,  optimal  solution.  The  system  is  homogeneous,  so  the  unique 
solution  is  A -  A*2  =  0.  Thus  the  A*'s  are  well-defined.  That  A**  =  A*  satisfy  the 
condition 

dfldxi  +  E  X/c  *dgk/dxi  =  0 

follows  from:  (1)  A*  has  the  same  value  for  all  decision  elements,  and  (2)  the  condition 
must  be  satisfied  for  a  decision  element  containing  jc/.  This  concludes  the  proof. 

Proposition  2:  Let  the  number  of  design  variables  in  each  decision  element  D, 
equal  or  exceed  the  number  of  constraints  in  D[  which  are  independent  and  active  at  a  point 
x*  determined  by  a  feasible,  optimizing  decision  sequence.  Then  if  x*  is  a  Kuhn-Tucker- 
Karush  point  for  the  original  problem  P,  all  of  the  optimal  sensitivity  derivatives  dfldxi 
will  be  0. 

Proof .  Certainly,  for  a  decision  element  Dj  determining  a  design  variable  xt ,  we 

have 

cflobci  +  E  Xfc  Idgic/dxi  —  0  , 

as  a  consequence  of  the  assumption  that  Dj  has  been  individually  optimized  in  Step  5  of 
each  iteration.  Dj  must  have  at  least  as  many  design  variables  as  independent  active 
constraints,  and  from  this  we  can  conclude  that  Afc  1  =  A*  *,  where  the  A*  *  are  the 
Lagrange  multipliers  corresponding  to  the  Kuhn-Tucker-Karush  point  for  the  entire 
problem.  We  verify  that  A*  1  =  A*  *  as  follows:  we  have  two  linear  systems 

dfldxi  +  E  X/r 1 dgkldxi  =  0  i  =  1 . no  i 

dfldxi  +  E  A*  *dgk/dxi  =0  i  =  1, . . . ,  noi 

where  noi  is  the  number  of  design  variables  in  the  decision  element  D]  .  The  first  of  these 
linear  systems  holds  since  Dj  is  optimized  during  each  solution  pass  through  the  sequence 
of  design  decisions.  The  second  system  holds  as  a  consequence  of  the  fact  that  x*  is  a 
Kuhn-Tucker-Karush  point.  Since  both  of  these  systems  have  a  unique  solution  (with  the 
derivatives  evaluated  at  x*),  the  system 

1  -  h  *  )dgk<dxi  =  0 

has  the  unique  solution  (A*  1  -  Xu  * )  =  0. 


Consider  the  case  where  xt  is  passed  to  a  decision  element  D2  as  a  parameter.  We 
wish  to  show 

dfl/dxi  =  dfldxi  +  E  Xjc  ^dgk/chi  =  0. 

D2  must  also  have  at  least  as  many  design  variables  as  independent  active 
constraints,  so  we  can  reason  as  above  that  the  Lagrange  multipliers  determined  by  the 
optimal  solution  of  D2,  A*  2,  are  equal  to  the  Lagrange  multipliers  corresponding  to  the 
Kuhn-Tucker-Karush  point.  A*  *.  Then  A*  2  =  Afc  *  =  A*  L 

Since  we  require  (Step  4)  that  the  number  of  parameters  passed  from  Dj  to  D2  must 
equal  or  exceed  the  number  of  independent  constraints  in  common  to  both  D 7  and  Z>2,  we 
know  that  solutions  exist  to  the  linear  system: 

dfldxi  +  Z  kinD2  fa2dgk/dxi  •  {dfldxi  +  E  k  in  di  A*  1  dggldxi  }  =  df2ldxi  . 
Since  dgkldxi  =  0  unless  gk  appears  in  D 7,  we  can  simplify  this  system  to 
z  kin  Dl  (A/fc  2  -  Ajk  l)dgjc/dxi  =  df2ldxi 
Z  kin  Dl  (A*  *  -  h  *)dgk!d*i  =  dfVdxi 
0  =  ZkinDl  (0 )dgk!dXi  =  df2/dXi  .  - 

Since  our  choice  of  decision  elements  was  arbitrary,  the  result  is  established. 

B.  OPTIMAL  SENSITIVITY  DERIVATIVES  AND  PARETO-OPTIMALITY 

We  now  turn  to  the  justification  for  the  equation  relating  optimal  sensitivity 
derivatives  and  Pareto-optimality. 

The  Pareto-optimal  solutions  minimize 

F  =  Za>ifi,  Icoj  si. 

For  the  moment,  fix  the  weights  co, .  Then  the  Lagrange  multipliers  are  constant  in 
the  equations  for  the  optimal  sensitivity  derivatives  with  respect  to  a  parameter  p , 

dfi  I  dp  =  dfi  / dp  +  E  XjdgjlBp  . 

Then,  using  E  o)j  =  1  and  the  linearity  of  the  partial  derivative, 
dF  Idp  =  dFIdp  +  E  Xjdgj  I  dp 

=  dldp  E(0\fi  +  E  Xjdgj  Idp 
=  E  coi<^i  Idp  +  E  coi  E  Xjdgj  /dp 


£  CDj  [dfi  I  dp  +  EXjdgjldp  ] 
X  oij  dfi  I  dp  , 


the  result  holding  for  an  individual  optimization  problem,  that  is,  without  any 
decomposition.  We  call  the  expression  dF  /dp  a  Pareto-optimal  sensitivity  derivative. 

Some  care  must  be  exercised  in  applying  the  equality 

dF/dp  =  £  coi  df  /dp 

across  the  subproblems  of  a  decomposed  problem.  As  in  the  rest  of  the  theory  developed 
in  this  appendix,  the  result  requires  the  equality  of  corresponding  Lagrange  multipliers 
determined  by  separate  optimization  subproblems.  We  have  only  obtained  the  equality  of 
the  Lagrange  multipliers  across  distinct  subproblems  when  the  derivatives 

df  /dp 

(taken  with  respect  to  any  local  design  variable,  Xi ,  appearing  in  other  decision  elements  as 
a  parameter,  p)  are  all  0,  or  alternatively  from  equality  of  the  sensitivity  derivatives  at  a 
Kuhn-Tucker-Karush  point.  In  the  developments  to  follow,  we  will  be  concerned  with  the 
case 


•  dF/dp  =  0, 

so  the  result  will  hold  across  a  decomposition  for  this  objective  function. 

Finding  a  balancing  sequence  of  design  decisions  is  done  at  Step  3  of  the  meta- 
^  design  procedure  (see  page  B-4). 

At  this  point,  we  have  available  the  optimal  sensitivity  derivatives  df  /dp  .  The 
basic  idea  is  to  investigate  the  effect  on  the  possible  optimal  decision  sequences  of  changes 
in  the  priorities  CD,  for  the  several  design  objectives.  This  naturally  involves  changing  the 

•  cox's.  Thus,  we  need  to  be  concerned  about  the  effect  changes  in  the  CDj's  may  have  on  the 
values  of  the  sensitivity  derivatives. 


1.  Dependence  of  the  Pareto-optimal  Sensitivity  Derivative  on  the 
Prioritization  of  the  Multiple  Objectives 

Proposition  3:  dF/dp  (co)  =  X  ©j  df  /dp  . 

Proof:  We  wish  to  know  the  effect  of  changing  the  prioritizations,  coi,  of  multiple 
objective  functions  on  the  Pareto-optimal  sensitivity  derivative,  dF/dp.  We  investigate  the 
nature  of  the  Pareto-optimal  sensitivity  derivative  as  a  function  of  the  CDj's  by  computing  the 
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derivatives  of  dF  /dp  (oo).  The  coi's  themselves  are  parameters,  so  we  ready  are  asking  for 
the  second  optimal  sensitivity  derivative  of  F ,  with  respect  to  coi  and  p ,  denoted  here  by 

Dp  mi optimal  F  . 

That  is,  we  wish  to  compute 

dFId  C0i  =  dF  Id  COj  +  £  kjdgj  Id  COj  =  fi 

and  then  ta^e  the  optimal  sensitivity  derivative  of  this  quantity  with  respect  to  a  parameter 
p.  This  second  differentiation  gives 

D p,  optimal  p  =dfi/dp 

Where  dfi  /  dp  denotes  the  optimal  sensitivity  derivative  of  the  objective  function  fi 
with  respect  to  the  parameter  p.  All  higher  optimal  sensitivity  derivatives  of  F  with  respect 
to  o>i  are  zero. 

Let  the  new  values  for  the  coi's  be  denoted  by  coii.  Then 

dF  I  dp  (coi)  =  X  C0i  dfi  I  dp  +  X  DPi  ^optimal  p  Acoj 

=  X  CDi  dfi  I  dp  +  X  dfi  I  dp  Acoj 
=  X  (o>i  +Ao>i )dfi  Idp 
-  X  toiidfi  Idp  . 

The  first  equality  holding  since  all  derivatives  higher  than  Dp  ^optimal  p  are  zero,  thus  the 
first  order  Taylor  series  is  exact.  This  is  the  desired  result,  since  we  have  shown  that  the 
effect  on  the  optimal  sensitivity  derivatives  dfldp  of  changing  the  cofs  can  be  computed  by 
just  formally  changing  their  values  in  the  expression  X  COj  dfi  Idp. 

2.  Application  to  Methodology  F 

Propositions  1  and  2  are  applied  to  methodology  F  of  Chapter  IV  by  noting  that  the 
optimality  conditions  dF  /dpi  (co)  =  0  for  the  approximate  Pareto-optimization  problem  are 
the  same  as  the  convergence  criteria  for  the  solution  of  the  exact  Pareto-optimization 
problem  by  a  parameter-passing  scheme.  We  thus  solve  the  exact  Pareto-optimization 
problem  when  we  satisfy  these  conditions.  Proposition  3  allows  us  to  satisfy  the 
conditions  by  varying  the  relative  prioritizations,  while  maintaining  the  significance  of 
those  conditions  in  terms  of  optimal  sensitivity  derivatives.  Thus,  propositions  1,  2,  and 

3,  allow  us  to  solve  the  exact  problem  by  varying  the  relative  prioritizations. 
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LANDING  GEAR  LAYOUT  FOR  MINIMUM 
RETRACTION  COMPLEXITY 


This  example  illustrates  the  solution  of  an  aircraft  design  problem  using  the 
procedure  described  in  Appendix  B.  The  role  of  approximation  techniques  in  bringing 
numerical  rankings  of  qualitatively  different  design  alternatives  into  the  design  decision¬ 
making  process  is  emphasized  in  this  example.  We  compare  the  solution  of  the  design 
problem  using  the  method  of  Appendix  B  with  a  numerical  optimization  solution  using  the 
dual  method  of  Schmit/Fleury.  Once  the  solution  is  converged,  the  results  are  identical,  as 
predicted  by  the  theory  developed  in  Appendix  B. 

Note  that  the  optimal  solution  to  this  problem  is  found  in  a  single  pass  through  a 
properly  planned  sequential  decision-making  process. 

A.  AIRCRAFT  SIZING  AND  INITIAL  LAYOUT-MAIN  LANDING  GEAR 
LOCATION 

In  this  examnle,  we  analyze  the  design  problem  of  determining  the  location  of  the 
main  landing  gear  (MLG)  on  a  small,  high-performance  piston-engine  racing  aircraft.  This 
design  problem  is  extremely  simple,  yet  elements  of  quantifying  the  qualitative  are  present. 
The  problem  is  typical  of  engineering  design  problems  in  which  constraints  on  the  design 
are  intended  to  preclude  various  failure  modes. 

There  are  several  ways  that  an  aircraft  can  fail  when  landing  or  on  the  ground. 
When  the  aircraft  is  taking  off,  landing,  taxiing,  or  parked  on  the  airfield,  a  gust  can  tip  the 
aircraft  over  about  a  line  from  the  MLG  wheel  location  to  the  nose  wheel  location.  To 
avoid  this,  the  track  angle  (also  called  the  lateral  tip-over  angle)  is  specified.  Reference  C- 
1  gives  a  value  of  55  degrees  as  the  maximum  allowable  for  this  angle.  Track  angle  is 
related  to  the  center  of  gravity  (CG)  location,  track,  wheelbase,  MLG  location,  and  nose 
landing  gear  (NLG)  location  by  the  equation: 

track  angle  =  atan[(MLGz  -  zcg)/((*CG  -  NLGx)*sin(atan(track/(2*wheelbase))))] 


Another  failure  mode  can  occur  on  landing.  High-performance  aircraft  often 
approach  the  runway  and  touch  down  at  relatively  high  angles  of  attack.  If  the  center  of 
gravity  is  behind  the  vertical  plane  of  the  main  landing  gear  wheels,  the  moment  of  the 
weight  of  the  aircraft,  acting  through  the  MLG  wheels,  about  the  center  of  gravity  of  the 
aircraft,  will  tend  to  sit  the  aircraft  on  its  tail.  This  occurs  as  the  weight  of  the  aircraft  is 
transferred  from  the  wings  to  the  landing  gear.  Restricting  the  angle  between  the  center  of 
gravity  and  the  plane  of  the  main  landing  gear  wheels  will  cause  the  aircraft  to  hit  its  tail  on 
the  mnway  (and  presumably  bounce  back)  before  it  can  come  to  rest  in  a  stable  position  on 
its  tail.  This  tail  down  angle  (also  called  the  longitudinal  tip-over  criterion)  is  related  to  the 
main  landing  gear  and  center  of  gravity  locations  by 

tail  down  angle  =  atan((MLGx  -  xcg)/(MLGz  -  zcg)) 

In  any  design  project,  the  design  team  will  have  goals  which  reflect  the  competitive 
strategy  the  team  seeks  to  execute  in  the  design.  In  this  example,  such  a  goal  is  to  minimize 
retraction  complexity. 

A  basic  principle  of  lightweight  structural  design  is  to  keep  the  load  paths  simple. 
The  loads  encountered  by  the  MLG  are  mostly  absorbed  by  the  shock  strut,  but  pan  of  the 
load  will  be  transmitted  to  structural  elements  in  either  the  wing  or  the  fuselage.  Using 
some  of  the  the  same  structural  elements  to  react  both  landing  and  in-flight  loads  results  in  a 
lighter  structural  weight.  In-flight  loads  on  the  fuselage  are  primarily  bending  resulting 
from  the  inertia  of  the  fuselage  structure  itself  and  the  weight  of  the  useful  load  carried  in 
the  fuselage  as  these  masses  are  suspended  from  the  wing  structure;  pressurization  loads 
(if  any);  and  torsional  and  bending  loads  resulting  from  aerodynamic  forces  on  the 
horizontal  and  vertical  control  surfaces.  Wing  torsion  and  bending  loads  resulting  from  the 
aerodynamic  forces  on  the  wing  and  the  inertia  of  the  wing  structure  (and  any  fuel  carried 
in  the  wing)  are  also  transmitted  to  the  fuselage. 

In  conventional  semi-monocoque  metal  aircraft  structural  design,  the  wing  and 
fuselage  are  stiffened  shells  formed  by  the  aircraft  skin,  fuselage  frames,  longerons  and 
bulkheads,  wing  spars,  ribs,  and  other  stiffeners.  These  elements  are  thin-walled  and  are 
designed  basically  to  react  shear  and  compressive  end  loads.  The  structural  elements  that 
are  available  to  react  the  landing  gear  loads  in  this  way  are  the  ribs  and  spars  in  the  wing 
and  the  longerons  and  frames  in  the  fuselage.  The  load  paths  will  usually  be  much  simpler 
if  the  landing  gear  loads  are  applied  to  a  fuselage  frame  or  wing  spar. 


For  many  racing  aircraft,  a  slight  speed  advantage  can  be  gained  by  using  as  large  a 
wing  span  as  possible  [Ref.  C-2],  subject  to  constraints  on  wing  loading  and  static  margin 
for  acceptable  handling  qualities  and  on  wing  structural  weight  (which  increases  in  rough 
proportion  to  the  wing  span).  The  wing  structure  will  be  lighter  if  the  landing  gear  is 
attached  to  the  fuselage.  Thus  the  MLG  location  is  constrained  by  the  fuselage  frame 
spacing.  The  fuselage  frame  spacing  is  constrained  by  producibility  considerations  (there 
must  be  adequate  room  to  work  between  the  frames)  on  the  low  end  and  by  structural 
elastic  stability  on  the  high  end. 

The  most  important  overall  goal  in  the  design  of  a  piston-powered  racer  is  to  get  as 
much  horsepower  as  possible  into  an  extremely  low-drag  package.  These  aircraft  fly  at 
relatively  high  dynamic  pressures  and  tend  to  be  lightweight  to  begin  with,  and  as  a  result 
parasite  drag  may  be  as  much  as  125  times  larger  than  induced  drag,  making  aircraft  wetted 
area,  r>nd  hence  aircraft  size,  much  more  ci.tical  than  aircraft  weight  The  drag  penalty  for  a 
fixed  landing  gear  is  not  acceptable.  Therefore  the  gear  must  be  retractable  and  must  fit  into 
a  small  space.  Reliability,  maintainability,  and  cost  will  be  adversely  affected  if  complex 
retraction  kinematics  are  required  to  accomplish  this.  Thus,  minimizing  retraction 
complexity  is  a  goal  for  this  example  problem. 

Retraction  complexity  is  a  qualitative  rather  than  an  inherently  quantitative  factor. 
In  practice,  a  numerical  ranking  for  such  a  factor  would  be  assigned  to  each  of  several 
alternative  designs  by  a  team  of  landing  gear,  structural  and  aerodynamic  designers,  and 
producibility  and  supportability  specialists.  Methods  for  developing  these  rankings  are 
outlined  in  reference  C-3.  For  the  purposes  of  this  example,  we  assume  a  numerical 
ranking  procedure  has  been  used  by  a  design  team  to  assign  rankings  to  four  alternative 
landing  gear  (LG)  arrangements  as  illustrated  in  Figure  C-l. 


Figure  C-1.  Numerical  Rankings  of  Retraction  Comolexity 
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The  example  problem  becomes  one  of  locating  the  main  landing  gear  (in  x,  y,  and  z  aircraft 
reference  coordinates)  in  such  a  way  as  to  minimize  the  retraction  complexity,  while 
satisfying  constraints  on  tail  down  angle  and  track  angle.  The  design  variables  are  thus: 
MLGx,  the  x-coordinate  of  the  main  landing  gear  location;  MLGy,  the  y-coordinate  of  the 
main  landing  gear  location;  and  MLGz,  the  z-coordinate  of  the  main  landing  gear  location. 
Side  constraints  on  each  of  the  design  variables  MLGx,  MLGy,  and  MLGz  are  derived  as 
follows.  The  x  coordinate  of  the  aircraft  CG  location  is  at  9.5  ft.  Thus  a  lower  bound  for 
MLGx  is  set  at  10  ft.  The  upper  bound  is  set  at  15  ft.  In  a  more  detailed  example,  the 
upper  bound  would  be  related  to  the  horizontal  tail  volume  coefficient  required  to  rotate  the 
aircraft  on  takeoff.  The  lower  bound  for  MLGy  is  set  by  the  fuselage  envelope  at  1  ft.  The 
upper  bound  for  MLGy  is  related  to  the  wing  span  and  is  set  at  15  ft.  The  lower  bound  for 
MLGz  is  set  by  the  shock  strut  length,  which  is  related  to  the  aircraft  weight,  design  sink 
rate  on  approach,  and  landing  gear  design  load  factor,  and  is  set  at  4  ft.  The  upper  bound 
for  MLGz  is  related  to  maintenance  access  and  is  set  at  7  ft  The  statement  of  the  example 
problem  as  an  optimization  problem  is 

Minimize:  retractionComplexity  (MLGx,MLGy,MLGz) 

Subject  to:  trackAngle  (MLGx,MLGy,MLGz)  <  55 

tailDownAngle  (MLGx,MLGy,MLGz)  >15 
10  <  MLGx  S  15 
1  <;  MLGy  <  15 
4  <  MLGz  <  7 

B  .  FORMULATION  OF  SUBPROBLEMS 

The  initial  structure  of  design  decision-making  tasks  is  based  on  the  idea  that  goals 
(such  as  minimize  retraction  complexity)  and  requirements  (such  as  tail  down  angle  >  1 5 
degrees)  are  propagated  through  choices  of  the  design  parameters  MLGx,  MLGy,  and 
MLGz.  In  this  example,  each  subproblem  corresponds  to  the  selection  of  a  value  for  one 
of  these  design  parameters.  The  relationships  among  attributes  and  constraints  of  the 
landing  gear  arrangement  problem  are  represented  by  a  directed  graph  in  Figure  C-2. 

The  initial  subproblem  structure  is  as  shown  in  Figure  C-3.  Problem  PI 
(determination  of  MLGx)  includes  constraints  that  are  linked  in  the  directed  graph  of  Figure 
C-2  by  the  design  variable  MLGx.  Thus,  since  MLGx  appears  explicitly  as  a  variable  in 
both  the  tail  down  angle  and  track  angle  constraints,  they  are  both  included  in  problem  Pi. 


MLGx  does  not  appear  explicitly  in  the  retraction  complexity  objective,  so  it  is  not  included 
in  PL  Problem  P2  contains  constraints  and  the  objective  function  in  which  the  attribute 
MLGy  appears  explicitly  as  a  variable.  Problem  P3  contains  constraints  and  the  objective 
function  in  which  MLGz  appears  explicitly  as  a  variable. 

The  meta-design  problem  is  to  formulate  the  subproblems  PI,  P2,  and  P3  to 
determine  a  convergent  parameter-passing  sequence  for  solving  them  and  to  identify  an 
iteration  strategy,  if  one  is  needed,  to  achieve  optimality  (or  near-optimality).  For  this 
example,  the  decision  support  tool  used  to  solve  each  of  the  problems  is  an  x-y  plot  with 
the  independent  variable  plotted  on  the  x-axis  and  the  objective  function  and  constraints 
plotted  on  the  y-axis.  Other  decision  support  tools,  such  as  carpet  plots,  could  be  used  to 
bring  additional  variables  into  each  subproblem.  Numerical  optimization  could  also  be 
used  to  solve  the  subproblems. 


Figure  C-2.  Graph  Representing  Relationships  Among  Attributes  for  Landing 

Gear  Arrangement  Example 


Problem  1 

Satisfy: 

track  angle  <  55 
tail  down  angle  >  15 


Problem  2 
Minimize: 

retraction  complexity 

Subject  to: 

track  angle  £  55 


Problem  3 
Minimize: 

retraction  complexity 

Subject  to: 

track  angle  s  55 
tail  down  angle  2 15 


Figure  C-3.  Initial  Subproblem  Structure 
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C .  APPLICATION  OF  THE  META-DESIGN  PROCEDURE 


The  first  step  in  the  meta-design  procedure  is  to  solve  the  individual  (one¬ 
dimensional  search,  in  this  case)  optimization/constraint  propagation  problems  PI,  P2,  and 
P3  as  self-contained  problems.  This  can  be  done  using  approximate  forms  for  the  goal  and 
constraint  design  attributes. 

1 .  Construction  of  Approximations 

Simple  mathematical  expressions  for  track  angle  and  tail  down  angle  as  a  function 
of  MLGx,  MLGy,  and  MLGz  were  presented  earlier  in  this  chapter.  In  this  section,  these 
simple  relationships  are  approximated  by  functions  that  are  linear  in  either  the  design 
variables,  Xi,  or  their  inverses,  1/xj.  This  form  of  the  approximating  functions  allows 
additional  flexibility  (relative  to  linear  approximation)  for  approximating  nonlinear  design 
relationships,  while  retaining  the  highly  advantageous  property  of  convexity.  The 
approximations  are  constructed  by  curve-fits  to  evaluation  of  the  objectives  and  constraints 
on  a  set  of  alternative  landing  gear  arrangements.  This  process  allows  rankings  of  the 
alternative  designs  based  on  the  qualitative  criterion  of  retraction  complexity  to  be  brought 
into  the  meta-design  process  on  the  same  basis  as  the  analytical  models  of  track  angle  and 
tail  down  angle. 

Many  producibility  and  supportability  considerations  must  be  brought  into  the 
conceptual  design  process  through  numerical  ranking  of  qualitative  criteria.  The  fact  that 
this  approximation  technique  allows  analytical  performance  and  cost  criteria  to  be  balanced 
against  producibility  and  supportability  considerations  is  an  ideal  match  to  unified  life  cycle 
engineering  (ULCE)  and  concurrent  engineering  objectives.  Using  the  approximation 
technique,  any  aspect  of  the  design  that  can  be  evaluated  at  some  level  can  be  brought  into 
the  trade-off  process.  This  aspect  of  the  approximation  technique  makes  the  approach 
highly  suitable  for  use  in  aircraft  preliminary  design,  detailed  design,  prototype  testing, 
even  production  and  initial  support  where  closed  form  analytical  solutions  are  often  not 
accurate  enough  or  available.  Methods  such  as  computational  fluid  dynamics,  finite 
element  analysis,  wind  tunnel  tests,  specimen  tests,  and,  ultimately,  operational  evaluations 
would  then  provide  the  evaluation  of  alternative  configuration,  production,  and  support 
arrangements. 


Results  of  evaluating  tail  down  angle,  track  angle,  and  retraction  complexity  for 
each  of  four  alternative  landing  gear  arrangements  are  presented  in  Table 
C-l.  MLGx,  MLGy,  and  MLGz,  the  coordinates  of  the  main  landing  gear  location 
(specifically,  the  centroid  of  the  main  landing  gear  tire  footprint),  are  used  as  independent 
variables  and  are  also  tabulated  in  Table  C-l. 

To  maintain  convexity,  the  coefficients  of  the  design  variables  or  their  inverses 
must  be  positive  for  the  objective  function  and  for  constraints  in  the  form  given  in  reference 
C-5.  In  this  example,  this  criterion  was  used  to  determine  whether  a  constraint  or  goal 
design  attribute  was  directly  or  inversely  proportional  to  a  decision  design  attribute.  Using 
this  procedure,  the  following  approximations  were  constructed: 

retraction  complexity  ~  0.6727*MLGy  +  0.775 l*MLGz 

track  angle  ~  55  -  (1.795*MLGx  +  78.91/MLGy  +  4.554*MLGz)  >  0 

tail  down  angle  ~  -  15  +145.2  -  (1 190/MLGx  +  3.916*MLGz)  >  0 


Table  C-1.  Results  of  Configuration  Evaluations 


Landing  Gear  Arrangement 

1 

2 

3 

4 

MLGx  (ft) 

12.00 

11.82 

13.41 

13.47 

MLGy  (ft) 

6.27 

6.87 

3.88 

3.88 

MLGz  (ft) 

4.78 

6.12 

5.82 

4.78 

Tail  down  angle 

27.00 

21.00 

34.00 

40.00 

Track  angle 

56.00 

61.00 

71 .00 

72.00 

Retraction  complexity 

8.10 

9.40 

7.10 

6.30 

At  least  for  this  example  problem,  approximations  can  be  found  that  provide  a 
reasonably  accurate  qualitative  picture  of  the  design  space.  Example  results  for  tail  down 
angle  (Figure  C-4)  are  typical.  These  qualitative  results  are  only  valid  locally,  however, 
and  can  be  quite  inaccurate  when  extrapolated  much  beyond  the  region  of  design  space  near 
the  alternative  configurations  that  were  evaluated  to  construct  the  approximations  (Figure 
C-5). 


Figure  C-4.  Tail  Down  Angle  as  a  Function  of  MLGx 


Figure  C-5.  The  Approximations  Are  Not  Usually  Accurate  Globally 


2 .  Monotonicity  Analysis 

Problems  PI,  P2,  and  P3  are  coupled  by  the  objective  function,  retraction 
complexity,  and  by  the  tail  down  angle  and  track  angle  constraints.  Thus  it  is  important  to 
know  how  the  constraints  and  the  objective  function  determine  the  design  variables.  This 
can  be  done  using  monotonicity  analysis  [Refs.  C-6,  C-7]. 

The  monotonicity  table  for  the  landing  gear  layout  problem  is  presented  in  Table 
C-2.  For  a  design  variable  such  as  MLGx  to  be  determined  by  the  objective  function  and 
constraints,  there  must  be  both  a  "+"  and  a  in  the  MLGx  column  of  the  monotonicity 
table.  A  "+”  is  entered  in  the  MLGx  column  at  the  track  angle  constraint  row  if  the 
constraint  is  increasing  with  MLGx.  (Note  that  the  constraints  must  be  written  in  a 
consistent  way.) 


Table  C-2.  Monotonicity  Analysis  for  the  Landing  Gear  Layout  Example 


MLGx 

MLGy 

MLGz 

Retraction  complexity 

Q 

G 

15 -tail down  angle  <0 

G 

G 

-55  +  track  angle  <  0 

O 

O 

O 

4  -  MLGz  <  0 

Q 

The  following  conclusions  may  be  drawn  from  Table  C-2: 

•  MLGx  may  be  determined  from  the  tail  down  angle  and  the  track  angle 
constraints. 

•  MLGy  is  determined  by  the  track  angle  constraint  and  the  objective  function. 

•  MLGz  is  determined  by  its  lower  bound. 

Using  this  information  and  the  solutions  to  the  one-dimensional  subproblems,  a 
convergent  sequence  for  solving  PI,  P2,  and  P3  can  be  found.  Initial  solutions  to  PI,  P2, 
and  P3  using  values  from  Landing  Gear  Arrangement  1  are  shown  in  Figures  C-6  through 
C-8. 
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Figure  C-6.  Solution  of  Constrained  Optimization  Problem  PI 


Figure  C-7.  Solution  of  Constrained  Optimization  Problem  P2 
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Figure  C-8.  Solution  of  Constrained  Optimization  Problem  P3 
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Note  that  in  Figure  C-6  although  monotonicity  analysis  indicated  that  MLGx  may 
be  determined  by  track  angle  and  tail  down  angle,  there  is  a  range  of  values  for  MLGx  that 
will  satisfy  both  constraints. 

The  meta-design  sequence  for  solving  PI,  P2,  and  P3  must  first  maintain 
feasibility.  This  means  that  if  we  specify  that  PI  is  to  be  solved  before  P3,  the  value  for 
MLGx  selected  in  PI  must  not  result  in  a  situation  where  there  are  no  values  of  MLGz  that 
will  satisfy  the  constraints  of  P3. 

To  evaluate  parameter  passing  schemes  for  feasibility,  we  examine  the  isolated 
solutions  of  Figures  C-6  through  C-8.  For  PI,  we  see  that  MLGx  cannot  be  precisely 
determined  from  PI  in  isolation,  but  that  MLGx  should  be  decreased  from  the  Landing 
Gear  Arrangement  1  value  to  find  a  feasible  solution.  Similarly,  MLGy  should  be 
increased  from  6.27  to  6.75,  and  MLGz  should  be  decreased  from  4.78  to  4. 

The  next  step  is  to  examine  the  effect  that  these  changes  in  the  design  variables 
would  have  on  the  other  subproblems.  This  can  be  done  by  taking  partial  derivatives  of  the 
constraints.  A  first  order  Taylor  series  approximation  to  the  constraint  then  indicates 
whether  a  change  in  a  design  variable  will  make  a  constraint  more  or  less  critical.  As  an 
example,  since  3(tail  down  angle)/3(MLGx)  is  positive,  decreasing  MLGx  will  decrease  the 
tail  down  angle.  Since  tail  down  angle  must  be  greater  than  15  degrees,  this  change  in 
MLGx  makes  the  tail  down  angle  constraint  more  critical  for  P3.  Decreasing  MLGz  will 
make  the  tail  down  angle  constraint  less  critical  for  PI.  Thus  PI  should  not  be  solved 
before  P3  if  we  wish  to  ensure  feasibility. 

The  track  angle  constraint  will  actually  be  made  less  critical  if  the  changes  in  the 
design  variable  values  indicated  by  Figures  C-6  through  C-8  isolated  subproblem  solutions 
are  made. 

Once  restrictions  on  the  possible  meta-design  solution  sequences  associated  with 
maintaining  feasibility  have  been  identified,  consideration  can  be  given  to  how  the  solution 
of  the  subproblems  can  be  sequenced  to  lead  to  an  optimal,  or  near-optimal,  solution  to  the 
overall  problem.  This  is  done  using  the  optimal  sensitivity  derivatives  of  the  solutions  to 
the  one-dimensional  subproblems. 

To  compute  these,  note  that  the  objective  function  does  not  apperr  in  PI,  thus  the 
optimal  sensitivity  derivatives  for  PI  are  all  0.  Also,  3(retraction  complexity )/9(MLGx)  = 
0,  and  since  none  of  the  constraints  (track  angle  or  tail  down  angle)  are  active  at  the  isolated 


optimal  solution  of  P3  (Figure  C-8),  the  optimal  sensitivity  derivative  D°Pl(retraction 
complexity)/D(MLGx)  =  0  for  passing  MLGx  to  P3.  (This  case  was  already  excluded 
because  the  results  might  be  infeasible.)  Also, 

D°Pl(re traction  complexity)/D(MLGy)  =  9(re traction  complexity )/3(MLGy)  for  P3. 

In  the  case  of  P2,  the  track  angle  constraint  is  active  with  Lagrange  multiplier 
(0.6727*6.752)/78.91  =  0.388.  Then 

Doptfretraction  complexity  )/D(MLGx)  =  0.388*1.795  =  0.697 
and 

Dop^retraction  complexity  )/D(MLGz)  =  (0.7751  +  0.388*4.554)  =  2.54 
These  results  are  summarized  in  Figure  C-9. 


Figure  C-9.  Optimal  Sensitivity  Derivatives  for  Parameter  Passing  Schemes 

To  maintain  feasibility,  we  have  to  solve  P3  first,  then  PI.  If  we  solve  P2  before 
P3,  the  retraction  complexity  will  actually  increase  by  0.6727*AMLGy.  On  the  other 
hand,  solving  P3  before  P2  will  allow  a  reduction  in  the  objective  function  by 
2.54*AMLGy.  Thus  P3  should  be  solved  before  P2.  Solving  P2  before  PI  will  have  no 
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effect  on  the  objective  function,  but  solving  PI  first,  and  then  P2,  will  allow  a  reduction  in 
the  optimal  value  of  the  objective  function  that  we  can  obtain  in  P2  by  0.697*DMLGy. 
Thus  the  best  meta-design  sequence  will  look  like  Figure  C-10. 


Note  also  that  passing  the  new  value  for  MLGy,  obtained  by  solving  P2,  back 
through  PI  and  P3  will  not  improve  the  objective  function.  Thus,  it  is  not  possible  to 
improve  the  objective  function  by  iteration  in  this  case. 

Naturally,  it  is  of  considerable  interest  to  see  how  closely  the  solution  obtained 
using  optimal  constraint  propagation  with  this  meta-design  sequence  comes  to  the  optimal 


Figure  C-10.  Design  Methodology  for  Landing  Gear  Layout  Problem 

solution.  This  comparison  is  made  next,  executing  the  meta-design  sequence  using  optimal 
constraint  propagation.  This  result  is  compared  to  an  optimal  solution  obtained  using  the 
Schmit/Fleury  technique. 

3.  Execution  of  the  Meta-Design 

The  solution  of  the  landing  gear  layout  problem  using  the  optimal  constraint 
propagation  proceeds  as  follows.  First,  P3  is  solved  as  in  Figure  C-8,  and  MLGz  is 
determined  to  be  4.  This  value  is  passed  as  a  parameter  from  P3  to  PI  and  P2  as  indicated 
by  the  sequencing  arrows  in  Figure  C-10.  Following  the  meta-design  plan,  PI  is  solved 
next,  now  with  MLGz  =  4.0.  MLGy  is  still  at  the  Landing  Gear  Arrangement  1  value  of 
6.27.  However,  the  optimal  value  of  the  retraction  complexity  that  can  be  obtained  in  a 
subsequent  solution  of  P2  (as  a  function  of  MLGx)  is  used  as  a  supplementary  objective 
function  for  PI  (Figure  C-ll).  This  problem  yields  MLGx  =  10.39.  MLGx  =  10.39  is 
then  passed  as  a  parameter  to  P2  (as  indicated  in  the  decision-making  sequence  shown  in 


Figure  C-10)  and  P2  is  now  solved  (Figure  C-12),  giving  MLGy  =  4.35  and  a  final  value 
of  the  retraction  complexity  objective  of  6.02. 

Solution:  MLGx  =  10.39 
MLGy  =  4.35 
MLGz  =  4.0 

retraction  complexity  =  6.02 


Figure  C-11.  Solution  of  PI,  Constrained  by  Optimality  of  P 2 


Figure  C-12.  Re-Solution  of  P2,  Using  Values  for  Parameters  Determined 

in  Previous  Decision  Elements 

•  D.  OPTIMAL  SOLUTION  USING  DUAL  METHODS  AND 

APPROXIMATION  TECHNIQUES 

Dual  methods  can  be  applied  to  give  meaning  to  the  idea  of  computing  optimal 
sensitivity  derivatives  when  the  parameters  take  on  values  in  a  discrete  set.  The  details  of 

•  accomplishing  this  are  beyon  1  the  scope  of  the  present  work.  However,  this  connection 
between  optimal  constraint  propagation  and  dual  methods  makes  it  worthwhile  to  include 
some  discussion  of  how  approximate  problems  of  the  form  used  here  can  be  quite  easily 
solved  using  the  technique  of  Schmit/Fleury.  Since  the  optimal  solution  of  the  landing  gear 

•  layout  problem  was  needed  for  comparison  with  the  optimal  constraint  propagation 
solution,  solution  of  this  problem  using  the  Schmit/Fleury  dual  method  is  included  here  as 
an  example. 

Consider  the  solution  of  the  approximate  problem  form  considered  in  Ref.  C-5: 

The  design  variables  are  <Xb- 

The  objective  function  (to  be  minimized)  is  approximated  by 

Zbwb  Ob'1. 
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and  the  constraints  by 


bq  -  2bC ijq  Ctb  ^  0. 


The  Lagrangian  for  this  problem  is: 

2b  wb  ®b"  ^  *  2q  ^-q  (bq  ■  2b  Cbq  Otb) 


and  the  dual  problem  can  be  stated  as: 

max  min  {2b  wb  ab'1  -  2q  Xq  (bq  -  2b  Cbq  ab)} 

X  a 


subject  to: 

amin  <  ab  ^  amax 

0  <  Xq. 

(The  particular  form  of  the  Lagrangian,  f  -  LXg  is  a  consequence  of  one  of  the 
Kuhn-Tucker-Karush  optimality  conditions  for  the  primal  problem.) 

If  a  unique  solution  to  the  minimization  over  a,  for  a  fixed  value  of  X,  exists, 
solution  of  this  minimization  problem  implicitly  defines  a  function  a(X).  For  the  explicit 
approximate  problem  form  above,  a(X)  is  given  as  follows: 


Solving 


d 

3  otb 


zb<-Wv^Cb«ab)} 


=  0 


gives 

0Cb2  =  wb/{2Xq  Cbq). 

Define 

Ctb2  =  Wb/{2  Xq  Cbq). 

If  the  minimization  solution  is  at  an  interior  point  (i.e.,  amin  <  ab  <  amax  is 
satisfied  as  a  strict  inequality)  then 

ab  =  ab2 

Otherwise,  if  ab2  >  [amax]2,  then  ab  =  amax,  and  if  ab2  <  [amin]2,  then  ab  = 
amin  Defining  a(X)  in  this  way  allows  us  to  write  the  dual  objective  function  as: 


4»(X)  —  Zb  Wb  Ctb(X)"^  -  Zq  Xq  (bq  -  Zb  Cbq  OCb(X)) 

Solution  of  the  original  problem  can  thus  be  reduced  to  solution  of  the  simpler  problem 
max  <|)(X) 
subject  to:  X  >  0 

This  basic  approach  can  be  used  for  other  approximate  forms  for  the  objective  and 
constraint  functions.  In  particular,  consider  an  objective  function  having  the  form  ZbWb 
otb,  and  constraint  functions  with  the  form: 

Zj  Cjq  ctj  +  Zj  Cjq  ar1  [Ecjn  C-l] 

where  i  indexes  the  variables  to  which  the  constraint  is  directly  proportional  and  j  indexes 
the  variables  to  which  the  constraint  is  inversely  proportional  (in  this  form  of  the 
approximation  functions,  the  variables  appear  directly  or  inversely,  but  not  both). 


For  this  form  of  the  approximation  functions,  a  zero  of  the  derivative  of  equation 

C-l  at  an  interior  point  is  given  by: 

ttb2  =  ab2  =  Z  Xq  Cbq/{wb  +  Z  Xr  Cbr). 

Solutions  at  amax  and  amin  are  found  as  before. 

The  primal  form  of  the  main  landing  gear  layout  problem  is 
minimize:  0.6727*MLGy  +  0.775  l*MLGz 
subject  to: 

55  -  (1.795*MLGx  +  78.91/MLGy  +  4.554*MLGz)  >  0 

130.2  -  (1190/MLGx  +  3.916*MLGz)  £  0. 

10  £  MLGx  £  15 
1  £  MLGy  <  15 
4  £  MLGz  £  7 

The  dual  problem  is  then 
maximize: 


0.6727*MLGy  +  0.775  l*MLGz  +  Xi*((1.795*MLGx 


+  78.91/MLGy  +  4.554*MLGz)  -  55) 

+  X,2*((l  190/MLGx  +  3.916*MLGz)  -  130.2) 


subject  to:  Xi  >  0,  i  =  1,2 


We  have 

min  {(0.7751  +  Xi*4.554  +  X2*3.916)*MLGz}  occurs  at  MLGz  =  4, 

4  <  MLGz  <  10 


for  all  feasible  X,,  i  =  1,2.  However,  both  MLGx  and  MLGy  potentially  involve  a  trade¬ 
off  between  the  objective  function  and  the  constraints.  MLGx  is  defined  as  a  function  of 
Xi  and  X2 


MLGx  = S 


10  if  102  >  r2 
r  if  102  <  r2  <  152 
L 15  if  r2  >  152 


,  X*  (1190) 

where  r  =  - 

Xx  (1.795) 


MLGy  is  a  function  only  of  Xi 

r  if  l2  <;  r2  <  152 
L 15  if  r2  >  152 


MLGy  = 


=  < 


where  r2  = 


X*  78.91 
0.6727 


Making  these  substitutions,  the  dual  objective  function  is  (ignoring  the  constant  terms 
coming  from  MLGz) 

14.57*  VXi  -  36.78*  Xi  +  92.44*  VXi  VX2  -  114.58*  X2. 

The  maximum  of  this  function  occurs  at  Xi  =  0.1614,  X2  =  0.0263.  Thus  an  optimal 
solution  is 

Xi=  0.1614,  X2  =  0.0263 
MLGx  =  10.39,  MLGy  =  4.351,  MLGz  =  4 
f*  =  0.6727*4.351  +  0.7751*4  =  6.0 

This  solution  agrees  precisely  with  the  solution  to  the  problem  obtained  using  the 
sequential  design  process  developed  earlier  in  this  appendix. 
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BALANCING  COST,  RISK,  AND  PERFORMANCE  IN 

AIRCRAFT  SIZING 


In  this  appendix  we  solve  a  multiobjective  aircraft  conceptual  design  problem 
explicitly  and  compare  this  solution  with  one  obtained  using  the  theory  developed  in 
Appendix  B.  The  theory  developed  in  Appendix  B  allows  us  to  determine  the  entire  family 
of  Pareto-optimal  solutions  using  only  the  solution  of  a  single  optimization  problem  for 
each  of  the  multiple  objectives  and  partial  derivatives.  The  explicit  solution  technique 
requires  us  to  solve  a  new  optimization  problem  to  determine  each  Pareto-optimal  solution 
in  the  family.  The  method  used  here  is  much  more  efficient  than  the  explicit  technique. 

1 .  Pareto-Optimality 

Pareto-optimal  solutions  for  multiobjective  optimization  problems  are  solutions  for 
which  no  one  objective  can  be  improved  without  making  one  of  the  other  objectives  less 
optimal.  The  selection  of  a  Pareto-optimal  solution  then  corresponds  to  a  prioritization  of 
the  objectives  (prioritization  may  include  ranking  all  of  the  objectives  equally).  Pareto- 
optimality  is  thus  an  appropriate  way  of  precisely  stating  the  goal  of  balanced  design. 

The  main  practical  difficulty  in  applying  Pareto-optimality  in  developing  a  balanced 
design  is  in  the  expense  of  finding  enough  of  the  possible  Pareto-optimal  solutions.  An 
approach  to  overcoming  this  limitation  through  design  process  planning  is  described  here. 

To  solve  a  Pareto  optimization  problem  (Ref.  D-l)  ,a  new  objective  function,/,  is 
defined  by  forming  the  product  of  each  of  the  multiple  objective  functions,  /,• ,  with  a 
weighting  factor  for  that  objective  function,  coj,  and  summing  over  the  index  variable,  i , 
for  the  multiple  objective  functions: 

/=Zo>i/i 

The  minima  of  /  are  Pareto  optimal  solutions.  We  approach  the  problem  of 
balanced  design  by  applying  the  techniques  of  Appendix  B  to  the  objective  function/.  The 
tools  we  have  available  to  design  the  design  process  are  alternative  groupings  of  design 
attributes  into  design  decision  elements  and  alternative  design  decision  sequences.  The 
results  of  Appendix  B  allow  us  to  use  those  tools  to  develop  a  design  process 
corresponding  to  a  given  prioritization  of  the  multiple  design  objectives. 


2.  Problem  Statement 

This  sample  conceptual  design/sizing  problem  can  be  stated  and  solved  explicitly 
as  a  multiobjective  optimization  problem: 

minimize:  F(co,L/D,Wto3SFC) 


subject  to: 

available_fuel_constraint  (Wfuel, Wto)  -  0 
required_fuel_constraint  (W  fuel>WTo3SFC,L/D,T]p,R)  >  0 
0  <  L/D  <  25 

4000  <  WTO  £  46,000  (lb) 

0.35  £  BSFC  £  0.95 


2000  <Wfuei<  23,000  (lb) 


where 


L/D 

WTO 

BSFC 

Wfuel 

Tip 

R 


lift-to-drag  ratio 
take-off  weight 

brake-Hp  specific  fuel  consumption 
fuel  weight 
propeller  efficiency 
range. 


For  this  example  solution,  qp  and  R  are  taken  to  be  problem  parameters  with  fixed 


values: 


fip  =  0.85 

R  =  25,000. 

The  available  fuel  constraint  is  based  on  a  curve  fit  of  fuel-burning  long-range 

aircraft: 

WTO  -  Wfuel  -  1-222  Wto0'8382  ^  0 
The  required  fuel  constraint  is  derived  from  the  Breguet  range  equation: 

Wfuel  *  Wto  (1  -  e-[R  BSFC/(375  r\p  L/D)])  >  Q 


D-2 


The  objective  function,  F,  is  the  weighted  sum  of  three  conflicting  goals: 


minimize  W-po 

L/D  as  low  as  possible  (below  25) 

BSFC  as  high  as  possible  (above  0.35). 

One  way  to  formulate  F  to  balance  these  goals  is  to  set 

F  =  cox/a  -  (L/D/25))  +  CD2/((BSFC/0.35)  - 1)  +  (1  -  a>i  -  C02)  WTo/10000 

Minimization  of  F  with  the  value  of  co  fixed  will  allow  us  to  find  Pareto  optimal 
solutions. 


a.  Discussion  of  the  Problem  Formulation 

The  maximum  lift-to-drag  ratio  for  a  subsonic  aircraft  is  given  by 

L/Dmax  =  (b/2)  *  V  (ree/f) 

where  b  is  the  wing  span,  e  is  Oswald's  planform  efficiency  factor,  and  f  is  the  parasite  (or 
equivalent  flat  plate)  area. 

Achieving  a  high  L/Dmax  requires  a  combination  of  advanced  aerodynamic  and 
structural  design.  The  maximum  bending  stress  in  the  wing  structure  is  directly 
proportional  to  the  wing  span,  so  increasing  the  wing  span  will  generally  require  either 
advanced  materials  (increasing  development  risk  and  cost)  or  additional  structural  weight. 

The  planform  efficiency  may  be  increased  by  tailoring  the  planform  shape,  airfoil 
section,  and  geometric  twist  to  optimize  the  span  loading.  Each  of  these  developments 
makes  the  aircraft  more  difficult  to  manufacture.  The  wing  can  also  be  expected  to  twist 
under  torsional  loads  encountered  in  cruising  flight,  and  since  the  magnitude  of  these  loads 
changes  with  differing  altitudes  and  cruise  speeds,  matching  the  aerodynamic  and  structural 
characteristics  of  the  wing  is  a  complex  multidisciplinary  optimization  problem. 

The  parasite  area  (zero-lift  drag  coefficient  multiplied  by  reference  area;  see,  for 
example,  reference  D-2)  can  be  reduced  by  making  the  aircraft  longer  or  increasing  cruise 
speed,  (thus  increasing  cruise  Reynolds  number)  as  long  as  the  wetted  area  is  not  increased 
and  the  transonic  drag  rise  is  avoided. 

The  conclusion  is  that  although  it  is  desirable  to  make  the  lift-to-drag  ratio  as  high 
as  possible  from  a  performance  point  of  view,  manufacturing  and  engineering  development 
cost  and  risk  considerations  drive  us  to  keep  L/D  as  far  below  the  upper  limit  of  25  as 
possible. 
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In  a  similar  argument,  considerations  of  engine  life  and  propulsion  system 
development  cost  and  risk  drive  us  toward  specification  of  a  brake-horsepower  specific  fuel 
consumption  as  far  above  the  target  value  of  0.35  as  possible.  The  Pareto-optimization 
problem  is  thus  to  balance  superior  performance  (as  quantified  by  minimum  take-off  gross 
weight  to  perform  the  mission)  against  development  cost  and  risk  and  operational  life. 

b.  Explicit  Solution 

Fuel  required  and  fuel  available  are  graphed  as  a  function  of  take-off  gross  weight 
(WTO)  in  Figure  D-l.  Feasible  solutions  are  to  the  right  of  the  dashed  line  on  the  take-off 
gross  weight  axis  and  lie  between  the  fuel  required  and  fuel  available  curves.  Since  these 
curves  are  typical,  the  minimum  Wjo  solution  for  any  values  of  L/D  and  BSFC  will  lie  at 
the  intersection  of  these  curves.  Thus,  both  constraints  are  active. 


Figure  0-1.  Fuel  Required/Fuel  Available  Problem. 

With  both  constraints  active,  they  are  both  equal  to  zero  and,  hence,  equal  to  one 
another.  This  allows  us  to  obtain  a  relationship  for  BSFC  in  terms  of  L/D  and  Wto- 

BSFC  =  60  675  7ip  L/D  (In  WTo  -  1.2372)/R. 
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Using  this  relationship,  we  can  find  interior  extrema  of  the  objective  function 
F(co,L/D,Wto3SFC)  by  setting  the  partial  derivatives  9F/3L/D  and  dF/dWjo  equal  to 
zero.  To  compare  solutions  obtained  using  this  approach  to  those  using  the  method 
outlined  in  Chapter  IV,  we  interpret  these  optimality  conditions  as  equations  to  determine 
the  values  of  the  relative  prioritizations  ©i  corresponding  to  various  values  of  L/D,  Wjq> 
and  BSFC.  The  difference  between  the  approach  we  are  taking  here,  and  the  approach  of 
Chapter  IV,  is  that  here  we  have  found  the  solution  to  the  Pareto  optimization  problem 
explicitly.  This  may  involve  considerable  computation  for  more  complex  problems. 

We  represent  the  entire  family  of  Pareto-optimal  solutions  by  solving  the  equations 
for  coi  and  o>2.  Then  we  have  two  equations  in  the  two  unknowns  ©1  and  0)2: 

A  co  =  b 

where 

an  =  1/(25(1  -  L/D/25)2) 

ai2  =  -BSFC/(0.35  L/D  (BSFC/0.35  - 1)2) 

a2i  = -1/10,000 

a22  =  [-60.675  qp  L/D/(0.35  R  WTO  (BSFC/0.35  - 1)2)]  -  1/10000 

and 

bi  =0,  b2  =  -  1/10000. 

These  solutions  can  be  presented  by  plotting  the  values  of  ©1  and  C02  as  L/D  varies 
for  fixed  values  of  Wto  (Figure  D-2)  or  as  Wjo  varies  for  fixed  values  of  L/D  (Figure 
D-3)  or  BSFC  (Figure  D-4)  (using  the  relationship  for  BSFC  in  terms  of  L/D  and  Wto)- 
Pareto  optimal  solutions  are  located  where  the  three  curves  intersect.  For  example,  in 
Figure  D-5,  Wto  =  20,000  lb,  BSFC  =  0.4,  and  L/D  =  22.4  is  a  Pareto  optimal  solution 
with  ©1  =  0.14,  0)2  =  0.20,  and  ©3  =  1  -  ©1  -  ©2  =  0.66. 


Figure  D-2.  Pareto-Optimal  Solution  Curves  -  Constant  Take-Off  Gross  Weight 


Figure  D-3.  Pareto-Optimal  Solution  Curves  -  Constant  L/D 


1 


Figure  D-4.  Pareto-Optimal  Solution  Curves  -  Constant  BSFC 


Figure  0-5.  A  Pareto-Optimal  Solution 
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3 .  Optimal  Sensitivity  Derivatives 


Optimal  sensitivity  derivatives  can  be  used  to  integrate  several  coupled  design 
decision-making  tasks  that  are  performed  in  sequence.  The  situation  considered  in  the 
development  of  the  optimal  sensitivity  derivatives  is  shown  schematically  in  Figure  D-6. 
Three  interrelated  design  decisions  must  be  integrated:  choosing  L/D  (lift-to-drag-ratio), 
choosing  BSFC,  and  choosing  WfUel  and  Wjo-  The  decisions  are  coupled  by  the  fact  that 
choices  for  Wfuei  and  Wto  are  restricted  by  the  fuel  required  constraint,  which  in  turn 
depends  on  the  values  of  L/D  and  BSFC. 

The  optimal  sensitivity  derivative  technique  is  based  on  the  idea  that  each  design 
variable  is  fixed  by  a  specific  decision.  The  design  variable  appears  as  a  parameter  in 
subsequent  decisions.  The  distinction  between  a  parameter  and  a  local  design  variable  is 
essential.  For  example,  the  lift-to-drag  ratio  is  fixed  by  the  "choose  L/D"  decision 
[represented  as  a  plot  of  the  lift-to-drag  ratio  penalty  function  (1/(1  -  (L/D/25)))  vs.  lift-to- 
drag  ratio  in  the  upper  left-hand  comer  of  Figure  D-6].  Lift-to-drag  ratio  is  a  local  design 
variable  in  making  this  decision.  The  lift-to-drag  ratio  subsequently  appears  as  a  parameter 
in  the  "choose  Wf^i  and  Wto”  decision  (plot  of  fuel  required  and  fuel  available  constraints 
as  a  function  of  Wto  in  Figure  D-6).  Parameter  passing  is  thus  a  way  to  relate  coupled 
decision  tasks  to  one  another. 


Figure  0-6.  Parameter  Passing  for  Optimal  Sensitivity  Derivatives 
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It  is  important  to  know  how  optimal  values  of  local  objective  functions  change  as 
the  parameters  are  varied.  For  example,  the  minimum  weight  aircraft  is  found  at  the 
intersection  of  the  fuel  available  and  fuel  required  curves  for  the  choose  Wfuei  and  Wxo 
decision.  This  intersection  point  will  shift  up  or  down  the  fuel  available  curve  as  lift-to- 
drag  ratio  and  brake-Hp  specific  fuel  consumption  are  varied.  Quantifying  these  rates  of 
change  is  the  purpose  of  the  optimal  sensitivity  derivatives.  The  optimal  sensitivity 
derivatives  thus  allow  us  to  define  the  (constrained)  optimal  value  of  an  objective  function, 
such  as  Wjo,  as  a  function  of  a  parameter  such  as  lift-to-drag  ratio. 

Optimal  sensitivity  derivatives  are  computed  by  applying  one  of  the  Kuhn-Tucker- 
Karush  necessary  conditions  for  optimality  and  using  the  fact  that  the  constraints  remain 
satisfied  to  simplify  the  total  derivative  of  the  objective  function  with  respect  to  the 
parameter.  Thus,  for  an  optimization  problem 

minimize:  f(x,p) 

subject  to:  g(x,p)  >  0 

the  total  derivative  of  f  with  respect  to  p  is 

df/dp  =  3f/3p  +  (3f/3x)  (dx/dp), 

recognizing  that  as  p  is  varied,  the  values  of  the  design  variables  x  will  be  adjusted  to 
maintain  optimality  and  feasibility.  The  idea  of  the  simplification  is  to  avoid  having  to 
compute  (dx/dp).  Since  the  x's  are  adjusted  to  maintain  feasibility,  we  have 

dg/dp  =  3g/9p  +  (3g/3x)(dx/dp)  =  0, 

so  3g/3p  =  -(3g/dx)(dx/dp). 

The  necessary  condition 

3L(x,p,A,)/3x  =  0, 

where  L(x,p,X)  is  the  Lagrangian,  f(x,p)  -  XTg(x,p)  relates 

(3f/3x)  =  A,T(3g/3x). 

Substituting,  we  have 

df/dp  =  9f/9p  +  (9f/3x)(dx/dp)  =  3f/3p  +  \T0g/3x)  (dx/dp)  =  9f/3p  -  XT  3g/3p. 

The  advantage  of  this  technique  is  that  we  can  compute  the  total  derivative  of  f, 
maintaining  optimality  and  feasibility,  from  partial  derivatives  and  the  Lagrange  multipliers 


X.  The  Lagrange  multipliers  can  be  computed  from  the  necessary  conditions,  so  this 
procedure  is  usually  more  efficient  than  computing  dx/dp  directly,  using  reoptimization  and 
finite  differencing. 

Optimal  sensitivity  derivatives  can  be  computed  for  the  sizing  example.  Consider 
the  choose  Wto  and  Wfuei  design  decision-making  task  described  above.  The  Lagrangian 
for  this  subproblem  is 

L(x,p,X)  :  WTO  -  Xi(Wfud  -  WTo  (1  -  e-tR  BSFC/(375  tip  L/D)])) 

-  h.  (Wto  -  Wfuei  -  1.222  WTO0-8382)- 
Here,  x  =  (WTO.Wfuel).  p  =  (L/D,BSFC,  R,  Tip)  (p  is  now  a  vector),  and 
X  =  (Xh  X2),  g(x)  =  (Wfuei  -  WT0  (1  -  BSFC/(375  tip  IVD)]), 

Wto  -  Wfuei  -  1.222  WTo0'8382) 

The  optimal  solution  is  given  by 

Wfuei  =  WTO  -  1-222  wTo0-8382 

WT0  =  eKR  BSFC/(60.675  np  IVD))  +  1.2372]) 

The  Lagrange  multipliers  are  found  by  solving: 

5L/3WTO  =  1  +  X.i(l  -  e-IR  BSFC/(375  TipL/D)])  -  X2  (1  -  1.024  Wto*01618)  =  0 

aivawfuei  =  -Xi  +  x2  =  o 

Then  since  Xi  =  X2, 

Xi  =  (e-IB  BSFC/(375  Tip  IVD)]) .  1.024  Wto'0-1618)*1  (Eq.D-1) 

We  also  have 

9f/3pi  =  0  (Wto  does  not  depend  explicitly  on  L/D),  and 

9gl/9pi  =  (WTO  R  BSFC/(375  T]p  L/D2))  e-P  BSFC/(375  Tip  IVD)]  (Eq.  D-2) 

Then 

df/dpi  =  dWTo/d  L/D  =  -X\  9gi/5pi 

For  a  numerical  example,  let  R  =  25,000  mi.,  BSFC  =  0.4,  Tip  =  0.85,  and  L/D  = 

20. 


Then 


Wtq  _  e[(25000*  0.4/(60.675*0.85*20))  +  1.2372])  =  55941 


h  =  (e-[25000*0.4/(375*0.85*20)])  .  1.024*(55941)-0-1618)-l  =  29.672 
3gl/0Pl  =  (55941  *25000*0.4/(375*0. 85*(20)2))*e^2s000*0.4/(375*0.85'20)]  _ 

914.06 

and  finally, 

dWro/d  L/D  =  -Xi  agi/api  =  -29.672*914.06  =  -27122.0 

The  optimal  sensitivity  derivatives  quantify  the  effect  of  changes  in  a  design 
variable  on  the  feasibility  and  optimality  of  another  design  decision  in  which  that  design 
variable  appears  as  a  parameter.  For  example,  say  a  constraint  that  Wjo  must  be  below 
46,000  pounds  is  imposed  on  the  choose  Wto  anti  Wfuei  design  decision.  Since  the  take¬ 
off  gross  weight  corresponding  to  a  lift-to-drag  ratio  of  20  is  55,941  pounds,  the  choose 
Wto  and  Wfuei  design  decision  is  now  infeasible.  The  optimal  sensitivity  derivative 
computed  in  the  numerical  example  above  can  be  used  to  approximate  this  situation  in  the 
choose  lift-to-drag  ratio  design  decision  as  follows:  the  desired  value  of  Wjo  is  46,000 
pounds  or  less.  We  can  approximate 

WTo*(L/D) 

=  optimal  (feasible)  value  of  Wto  as  a  function  of  L/D 
=  WTO*(20)  +  (dW To/dL/D)(L/D  -  20) 

=  55941  -  27122*(L/D  -  20) 

This  approximation  is  reasonably  accurate,  as  seen  in  Figure  D-7  (where  AWto  = 
Wto  (L/D)  -  46000),  but  slightly  underpredicts  the  value  of  L/D  required  to  satisfy  the 
46,000  pounds  constraint.  The  linear  approximation  predicts  that  an  L/D  of  20.37  is 
required.  The  exact  solution  is  closer  to  20.41,  but  this  is  not  a  significant  difference. 


Figure  D-7.  Accuracy  of  Linear  Approximation  to  Optimal  Value  of  W-fo 

4.  Solution  Using  the  Theory  of  Appendix  B 

Using  the  theory  developed  in  Appendix  B,  we  can  approach  the  problem  of 
balancing  the  goal  of  minimizing  the  L/D  risk  against  the  goal  of  minimizing  the  take-off 
weight.  The  basic  idea  is  to  place  each  goal  in  a  separate  optimization  subproblem  and  then 
to  use  optimal  sensitivity  derivatives  to  balance  the  subproblems. 

Following  this  method  of  attack,  subproblems  are  identified. 

Pi: 

minimize:  fi  =  1/(1  -  (L/D/25)) 

subject  to: 

hj  =  LTD  -  pi  =0 

10£LVDi£25 

design  variables:  L/D 


where  pi  is  a  parameter.  Problem  P2,  associated  with  BSFC,  will  be  defined  after 
Problem  P3: 

P3- 

minimize:  f3  =  Wto/10000 
subject  to: 

gl  =  Wfuel  -  Wto  (1  -  e-P  BSFC/(375  hp  IVD)])  >  0 
g2  =  Wto  -  Wfuel  -  1.222  Wto0'8382  ^  0 
h3  =  LTD  -  pi  =  0 
fi4  =  BSFC  -  p2  =  0 

design  variables:  Wjo.W fuei,L/D,BSFC. 

{ side  constraints  which  will  not  be  used  in  this  example) 

For  the  moment,  take  BSFC  =  p2,  so  that  the  fourth  constraint  in  P3  is  identically 
satisfied.  Balancing  these  subproblems  should  correspond  to  the  idea  of  balance  inherent 
in  the  concept  of  Pareto-optimality,  namely  that 

F  =  coifi(L/D)  +  C03  f3(Wxo) 

should  be  minimized,  with  <01  +  ©2  +  C03  =  1.  (Since  BSFC  =  constant,  o>2  =  0.) 

From  the  point  of  view  of  parameter  passing,  the  only  tool  we  have  available  for 
balancing  the  subproblems  is  the  coupling  parameter  p.  Thus  it  seems  natural  to  try  to 
choose  a  value  for  p  in  such  a  way  that  F  is  minimized,  while  optimality  and  feasibility  are 
maintained.  With  this  in  mind,  optimal  linear  approximations  to  fi  and  f3  are  constructed, 
given  an  initial  value  pi0  for  pi  and  an  approximation  to  F  in  terms  of  the  optimal  linear 
approximations  is  'written: 

F~  =  G>i(fi*(pi°)  +  (dfi/dpi)Dpi)  +  0)3  (f3*(pi°)  +  (df3/dpi)Dpi) 

=  [o)i(dfi/dpi)  +  0)3  (df3/dpi)]  pi  +  constant, 

so 

3F/9pi  =  coi(dfi/dpi)  +  ©3  (df3/dpi)  =  0 
the  first  equality  holding  if  all  the  derivatives  in  it  are  defined. 

Thus,  a  Pareto-optimal  solution  corresponding  to  fixed  values  of  the  weightings  co 
when  the  parameter  pi  satisfies 


G>l(dfi/dpi)  =  -CD2  (df2/dpi). 


To  complete  this  example,  we  verify  that  solutions  obtained  by  this  parameter¬ 
passing/optimal  sensitivity  derivative  technique  are  in  fact  the  Pareto-optimal  ones,  which 
can  in  this  case  be  obtained  explicitly  (as  was  done  earlier  in  this  section). 

An  additional  subproblem  is  associated  with  choosing  the  BSFC. 

P2: 

minimize:  f2  =  l/(BSFC/0.35)  - 1) 

subject  to: 

h2  =  BSFC  -  p2  =  0 

0.3501  £  BSFC  £  0.95 

design  variable:  BSFC. 

For  a  numerical  example  to  compare  with  the  explicit  Pareto-optimal  solutions 
obtained  earlier  in  this  appendix,  the  following  optimal  sensitivity  derivatives  are  needed: 

dfi/dpi  =  3fi/9pi  -  jii3hi/3pi  =  \i\ 

pi  can  be  found  using  the  necessary  condition 
dfl/9L/D  -  pi9hi/3UD  =  0 

so  3fi/3L/D  =  M.i=  dfi/dpi. 

Similarly,  3f2/3BSFC  =  df2/dp2-  A  straightforward  argument  using  derivatives 
computed  for  the  explicit  solution  yields 

dfydpi  =-A.iOgi/0pi)/lOOOO 

and 

dfydp2  =  -X,i(9gi/3p2)/10000 
where  Xi  and  9gi/9pi  given  by  Equations  D-l  and  D-2  and 

3gl/3p2  =  WTO  (-R/C375  hp  L/D))  e-P  BSFC/(375  qp  LTD)] 

Application  of  Equation  D-3  then  gives  two  linear  equations  that  can  be  solved  for 
©i  and  0)2: 

<*>l  =  (df3/dpi)(df2/dp2)/[(df3/dp2)(df3/dpi)  -  ((dfi/dpi)  -  (df^dpi))  ((df2/dp2)  -  (dfsAte))] 
C02  =  (®i(df3/dp2)  -  (dfydp2))/((df2/dp2)  -  (df3/dp2)). 


These  solutions  can  be  plotted  parametrically  for  comparison  with  the  explicit 
Pareto-optimal  solutions.  This  has  been  done  in  Figure  D-8. 


1 


cop 


Figure  D-8.  Pareto-Optlmai  Solutions  Obtained  Using  Optimal  Sensitivity 

Derivatives 

The  results  in  Figure  D-8  should  be  compared  with  the  explicit  solutions  shown  in 
Figure  D-4.  Clearly,  the  optimal  sensitivity  approach  produces  the  same  solutions  as  the 
explicit  technique. 


D-15 


REFERENCES 


D-l.  Cohon,  J.L.,  Multiobjective  Programming  and  Planning,  Academic  Press,  New 
York,  1978. 

D-2.  Perkins,  Courtland,  and  Hage,  Airplane  Performance,  Stability  and  Control. 


